What makes a good project brief?

A good brief describes the problem and the business, not the deliverable.

Bad brief: "Build me a mobile app with a login screen, dashboard, notifications, and payment integration. Timeline: 3 months. Budget: TBD."

Good brief: "Salon owners waste 30 minutes daily on appointment management. We want to save them time and charge $50/month. We have 6 salon owners willing to test it. Budget: $6K."

A good brief covers five things. Who you're serving — specific people, not generic "users." The problem and evidence it exists. The business model and value exchange. Real constraints: actual deadlines, realistic budget. And openness: describe the outcome, not the solution, and invite the developer to propose the right shape.

Budget matters because it tells the developer how much risk the founder is willing to take. Small budget means find the smallest validation approach. Bigger budget means build a proper MVP. Budget plus problem plus hypothesis equals enough to scope something real.

Worth Building is the discipline of asking whether the problem deserves a solution before writing code. Find the Core identifies the one capability that creates competitive advantage. Appetite, Not Estimates fixes time and budget first, then flexes scope. Onboarding turns the brief into a structured discovery process.