
By Thomas Cohen, founder of Maestro
How to write an application brief: the perfect brief does not exist, start messy
A brief's blank page blocks more projects than the budget. A disorganised twenty-minute draft is enough to start, provided someone then asks the questions you missed and returns a clean document for your signature.
To write an application brief, begin with the messiest draft you can tolerate: the problem, who uses it, what wastes your time. On Reddit (r/vibecoding, June 2026), a project owner names the blockage: 'my weakness is not knowing how to write that initial design'.
What stops you at the blank page
Three things stop a business owner writing. They lack technical vocabulary and fear looking amateur; we devoted an article to that false problem, the tool should translate. They do not know the right detail level, so write three lines or forty pages. And they wait until everything is decided, although half the decisions only become visible while writing.
The messy draft, in twenty minutes
Take a sheet and write without rereading. State the problem in one sentence with a dated example from last week. Name the users and their actual jobs. List three manual tasks costing time. State one thing the software must never do. Describe what happens when things go wrong: a rejected quote, cancelling customer, late order. This draft contains contradictions and holes. It is usable, which is all we ask.
What a good question does to a draft
Questions turn messy into clean. At Maestro, Margaux opens scoping and interrogates your draft: who may edit a sent quote, what happens when a customer changes their mind after preparation, how many people work on one record simultaneously? These are not traps; they expose decisions made daily without formulation. An agent team asking questions is better than one guessing, and we showed what an AI guesses when nobody asks anything.
The clean version returns for your signature
Margaux then proposes a written French brief, read in fifteen minutes. You correct errors, add omissions, and say 'Looks good to me'. Victor writes the specification stating what the product must do, and the same gate closes before it. Nothing is built first. This reverses the usual order: you correct the document rather than write it, an exercise every owner can perform. If you prefer holding the pen, the timed one-hour method remains valid and gives better results when you already know the subject thoroughly.
What a messy draft cannot solve
One limit deserves stating. When several people have different product ideas, no brief reconciles them alone: everyone nods at the same document while imagining something else, and disagreement returns at delivery. We wrote about an approved document not being an agreement. In that case, a human facilitator around a table beats a tool, and an agency selling a scoping workshop earns its fee.
Tonight's draft
Open a notebook and allow twenty minutes with a timer: problem, people, three time losses, one prohibition, one scenario going wrong. Seek neither outline nor vocabulary. Tomorrow give it to someone whose job is asking questions, a consultant, provider, or agent team, and judge the questions asked before the first line of code. Someone building without a single question returns a product resembling your draft, crossings-out included.
Read the complete guide: build an application without coding