Insights · Planning · 17 June 2026
How to write a one page brief for an app
Every stalled build we have seen shared a root cause: nobody wrote down what was being built. One page fixes it, and writing that page takes an afternoon.
We once watched two cofounders argue for forty minutes about a feature, until someone asked each of them to write one sentence describing who the app was for. The two sentences described two different products. Six weeks of confusion, explained in under a minute.
Every stalled build we have seen shares that root cause: the thing being built was never written down. The fix costs one page and one afternoon, and this post is the template.
Why one page, exactly
A brief is not a specification. Specifications describe every screen and belong to a later stage. A brief describes the point, and one page is the discipline that makes it honest: if the idea does not fit, the idea is not clear yet, and no amount of building will clarify it.
The page earns its keep twice. First at the start, where writing it surfaces the disagreements while they cost a conversation. Then for the whole build, as the referee: scope arguments in week six get settled by what the page says, which is faster and kinder than settling them by who argues longest.
The six questions the page answers
Who is this for? One sentence naming a real person or role. "Freelancers who invoice monthly" is an answer. "Millennials" is a market segment wearing a trench coat.
What job does it do? The single task the user completes, written as a verb. Track, book, send, learn. If the honest answer is three verbs, you are writing three briefs, and it is much better to know that today.
Why will they choose it? The one honest reason someone switches from whatever they do now, even if what they do now is a spreadsheet and a group chat. Switching is expensive for users. Name the payoff that covers the cost.
What is the loop? The action they repeat. This is what the first version must do beautifully, and the sentence the whole build keeps returning to.
What does success measure? A number you can read after launch: weekly returning users, completed bookings, invoices sent. Not a feeling, and not downloads, which measure marketing rather than the product.
What waits for version two? The features already imagined and deliberately postponed, written down. This list is the difference between cutting scope and losing arguments about scope.
What to do with the page
Send it to everyone who will build, fund, or veto the project, and ask for objections in writing. An objection to a page costs a day to resolve. The same objection to a half built app costs a month.
Then keep it visible for the whole build, because new ideas will arrive weekly, and the question for each one is never whether it is good. Most will be. The question is which line of the page it serves. An idea that serves no line goes to the version two list with full honours, and the build keeps its shape.
A starting template
Six lines, ready to fill: For [person]. Who needs to [job]. They will choose it because [reason]. The loop is [action they repeat]. It worked if [number] by [date]. Waiting for version two: [list].
Fill it badly in twenty minutes, then argue about it, because the arguing is the point: every disagreement it surfaces now is a week it saves later. When the page stops changing, you are ready to talk to builders, and you will be startled how much sharper those conversations get when everyone is holding the same piece of paper.