Half the founder calls I take start with "I need to build X and I'm not sure how to describe it." That's a scoping problem, not a product problem. The developer on the other end of the conversation is trying to quote a thing that doesn't exist yet in writing, and both of you are guessing.
This post is the brief template I ask founders to send me before the first call. It's one page. It takes an afternoon. It saves 4–8 weeks on a typical build.
The template — copy this
Paste this into a Google Doc or a Notion page, fill every section. Don't skip. The empty ones are the ones that cause the most pain later.
Project name: [working title, fine if rough]
One sentence about what you're building:
A platform where [who] can [do what] so that [outcome].
Why now? (1–2 sentences on why this is the right time — launch window, funding, market shift)
The three user flows that must work for v1:
The one metric that tells us this worked: (a number, not a dashboard)
The integrations that must be live on day 1: (Stripe? Resend? Supabase? Clerk? Be specific.)
Hard constraints:
- Deadline and the reason:
- Budget range:
- Target platform(s): web / iOS / Android / all
- Languages / locales:
What already exists:
- Figma / designs:
- Brand guidelines:
- Existing code or accounts (Stripe, Vercel, etc.):
- A domain:
What you're explicitly not building in v1: (the cuts — see below)
How decisions get made:
- Who signs off on design?
- Who signs off on scope changes?
- Your response time commitment (48 hours works for most projects):
One page. 300–500 words once filled in.
Why each section matters
"One sentence about what you're building"
The template forces who × action × outcome. That combination kills vagueness. "A platform for creators" fails the test. "A platform where independent music teachers can sell recorded lesson packs so they earn recurring revenue from existing students" passes.
If you can't fill the sentence, you're not ready to brief. Spend a week iterating on the sentence. Show it to 3 people who match the "who." Adjust.
"Why now?"
Projects without urgency drift. The "why now" tells the developer whether your deadline is a real thing (conference demo, funding close, seasonal window) or a nice-to-have. It changes how they scope, what they cut, and whether they take the project at all.
Good: "Funding close is September 15, and we want to show paying users by then." Weak: "We'd like to launch soon."
"The three user flows"
Three is the cap. Not five. Not "flexible."
A flow is: starts somewhere, ends with a value delivered. "Buy a ticket" is a flow (land → browse → pay → get confirmation). "Dashboard" is not a flow — it's a surface. Flows have verbs and endings.
If you have five flows you can't cut, you have two products pretending to be one. Pick which one ships first.
"The one metric"
Founders resist this one the hardest. "We have lots of metrics." No. One. The forcing function of a single metric isn't measurement, it's argument-resolution during the build. Every "should we add X?" gets measured against the one metric.
Good: "50 paying customers in the first 90 days." Good: "1,000 weekly active event organizers." Weak: "Traction, growth, validation."
"The integrations"
Each integration line item is 3–8 days of actual work including production edge cases. A founder who lists 12 integrations on day 1 is quoting a 6-month project whether they know it or not.
Stripe is not "Stripe." Stripe subscriptions, Stripe Checkout, Stripe Connect with split payments, and Stripe Invoicing are four different integrations with four different complexity profiles. Be specific.
"Hard constraints"
Three numbers save more projects than any technical choice:
- Budget range. "€15–30K" is fine. "€20K ceiling" is fine. Giving a range instead of a number saves both sides from the posturing dance.
- Deadline + reason. A deadline without a reason is a wish. A deadline with a reason is a contract.
- Platforms. Web only? Responsive web + iOS? The doubling of scope when you add a platform is the single largest quote-mover.
"What already exists"
If you have Figma, the build is 30% faster. If you don't, the dev is designing and building, which slows everything. State it honestly. Saying you "have designs" when you have three Figma screens and a mood board pushes a difficult conversation to week 2 instead of day 0.
"What you're explicitly not building"
This is the section that separates good briefs from great ones.
Writing down what you're not doing is harder than writing down what you are. But it prevents 80% of the "while we're at it" creep that kills fixed-scope projects.
Example cuts from real briefs:
- Not: custom admin dashboard. Instead: direct DB access for us, proper admin in phase 2.
- Not: email template design. Instead: plain-text transactional emails.
- Not: role-based permissions beyond owner/user. Instead: everyone is an owner for v1.
- Not: native mobile app. Instead: responsive web only.
- Not: multi-language. Instead: English only at launch.
List the cuts. A developer reading "here's what I'm not building" exhales in relief — it means you've thought about scope.
"How decisions get made"
The line that matters: response time commitment.
If I ship a demo on Friday and you respond on Thursday, I've lost half of next sprint. Most projects that slip do so on approval latency, not implementation. Put "48 hours for decision or implicit approval" in the brief. It feels aggressive; it isn't. It's how projects ship.
The three questions that matter more than any Figma
After the brief exists, three questions are more diagnostic than any design file:
1. What's the smallest version of this you'd still ship?
If the founder answers with a list of 8 features, they aren't ready. If they answer "these three flows, and the rest can wait" — green light.
2. If this launches exactly as scoped, what's the chance you'll want to rebuild it from scratch in 18 months?
A founder who says "probably high" is telling you the MVP is a throwaway prototype. That's fine — but then scope accordingly (faster, cheaper, less polish). A founder who says "low, this should scale to our first 1000 customers" needs a different quote and architecture.
3. Who is going to run this product after launch?
If the answer is "you, I guess?" — pause. A founder who plans to hand off operations after launch needs much more documentation, handoff, and support than one who'll be the operator themselves. That's scope, too.
What not to put in the brief
Keep out of the one-pager:
- Detailed UI descriptions ("the button should be blue with a gradient"). That's Figma territory.
- Full feature lists with sub-features. If it doesn't fit in three flows, it's phase 2.
- Marketing copy for the finished product. You'll write that in week 8.
- User personas beyond "who" in the one-sentence. Save the 40-slide persona deck for later.
- Competitor analysis. If it informs your "who × action × outcome," mention it in one line. Otherwise skip.
The brief is for the build, not for the investor deck.
The common objections
"This feels reductive. My product is more complex."
Most MVPs aren't. The exercise of reducing forces you to find the core. If after an honest attempt you still can't reduce, the project is larger than an MVP — and the brief for a larger project is different (it needs a phased roadmap, not a one-pager). Either way, the one-page brief tells you which situation you're actually in.
"I don't know enough to write this yet."
Then do a discovery engagement first. 1–2 weeks, fixed price, output is the brief. Starting implementation without a brief is more expensive than paying for a brief.
"My developer said they don't need one."
Ask them how they quote without a brief. The honest answer is "I guess and pad 30%." Fine for small work. For an MVP, you're paying the padding and still getting guesswork. Insist on the brief anyway — the exercise of the developer reading a brief flushes out their questions before the contract.
What to do with it
Send it to 2–3 developers. Ask each for a milestone breakdown and a fixed quote. Compare the quotes and the questions each dev asked after reading the brief. The dev who asks the sharpest questions is usually the one who'll ship.
If you'd like a second pair of eyes on a brief before sending it, I'll read yours and send one page of feedback free. No commitment — if the fit's wrong I'll tell you and recommend someone else. Send it via the contact form.