Software rarely goes wrong because someone wrote bad code. It goes wrong because of a sentence nobody said out loud. The developer, or the AI assistant, filled the gap with a reasonable guess, and the guess was not what you meant.
This is the list of sentences to say. It works for a freelancer, an agency, or an AI coding assistant, because all three need the same things and none of them can read your mind.
The seven things
1. Who uses it
One specific person, described the way you would describe them to a friend. Not "small businesses". "The owner of a two-chair hair salon who does the books herself on Sunday evening."
Why it matters: it decides whether the thing runs on a phone at a counter or a laptop at a desk, how much explaining the screens must do, and how much patience you can assume.
2. What happens today, step by step
Describe the current process as it really is, including the ugly parts. "She photographs receipts with her phone, messages them to herself, and on Sunday types them into a spreadsheet. Some months she skips it and catches up in March."
Why it matters: the new thing has to fit into that reality, and half your requirements are hiding in it.
3. What sets it off
What makes someone open your app: a customer emails, a delivery arrives, it is Monday morning, someone scans a code. Software is a chain of reactions, and if nobody can say what starts the chain, the thing gets built as a screen that no one has a reason to open.
4. What goes in
Be concrete about the input, and bring three real examples: an actual email, an actual photographed receipt, an actual spreadsheet. Not made-up ones, because the mess is the point. A developer or an assistant seeing your real data will spot problems you would never have thought to mention.
5. What comes out
Describe the result as the user experiences it, not as a feature. "A one-page summary she can send to her accountant" rather than "reporting functionality".
If you can sketch it on paper, sketch it. A photograph of a drawing is worth two pages of description.
6. The rules and the exceptions
This is where the real work lives, and it is the section people skip.
- What must always be true? "A booking can never be double-sold."
- What must never happen without a person? "No money leaves without her tapping approve."
- What happens when something is missing, late, duplicated or wrong?
- Who is allowed to see what?
Every exception you name now is a bug you do not pay to find later.
7. What "done" looks like
One sentence that can be checked by a person who was not in the room:
I can photograph ten receipts and, within a minute, see a list with the right amounts and dates, and export it as a file my accountant accepts.
Without this, "done" becomes an argument. With it, it is a test anyone can run.
A template you can copy
WHO IT IS FOR
One sentence about one real person.
WHAT THEY DO TODAY
The current process, step by step, including the annoying parts.
WHAT STARTS IT
The event that makes them open this.
WHAT GOES IN
The inputs, and three real examples attached.
WHAT COMES OUT
The result, described as they would experience it.
RULES THAT CANNOT BREAK
- Must always be true: ...
- Must never happen without a person: ...
- When something is missing or wrong: ...
DONE MEANS
One checkable sentence.
NOT IN THIS VERSION
The things I know I want later, so nobody builds them now.That last section saves more money than all the others. Naming what you are not asking for stops a helpful developer or a very helpful AI from building it anyway.
What not to specify
Do not choose the technology. Saying "build it in React with a Postgres database" when you do not know what those are has one effect: it removes the expert's judgment and leaves you with their obedience. Describe the outcome and the constraints, and let the person or the tool choose the parts.
Two constraints are worth stating, because they are business decisions rather than technical ones: where data may be stored (if you have a legal reason) and what you are willing to spend to run it.
Using this with an AI assistant
An AI coding assistant takes this brief better than most humans, with one adjustment: give it one section at a time and check the result before moving on. Paste the "who it is for" and "what comes out" parts, ask for the smallest version that produces that output, look at it, then add the rules one by one.
Asking for the whole brief at once produces something that looks finished and hides its mistakes. See how to install Claude Code for the setup and the working rhythm.
Before you send it to anyone
Read your brief and mark each feature as one of three things: the AI has to make a judgment, an ordinary rule decides it, or a person decides it. If you cannot mark a line, that is the line to talk about first. The guide on whether your idea needs AI explains how to tell the difference, and the free check on this site does the same pass over your description automatically, feature by feature.