An app brief describes the problem, the users, what the first version must do and how success will be measured. It does not need technical detail. A good brief fits on two to four pages, lists the core user journeys as plain sentences, names the systems the product must connect to, and states the budget range and target date. Development companies use it to give you a comparable, realistic quote.
A brief is the document you hand to a development company so they can understand what you want and tell you what it will cost. Founders often think it needs wireframes, a technology choice and a feature list of a hundred items. It needs none of those. It needs clarity about the problem, the people and the outcome. Here is the structure we ask our own clients to use, with guidance on each section.
What does a good brief contain?
1. The one-line summary
One sentence: who it is for, what it does, why it is different. "A booking and payment app for independent yoga studios that replaces phone calls and bank transfers." If you cannot write this line, finish validation first.
2. The problem and the user
Half a page. Who has the problem, how they deal with it today, what it costs them. Use the words your interviews gave you. If there are two kinds of user, such as a customer and a business, describe both.
3. The core user journeys
The most important section and the one founders skip. Write five to ten plain sentences that each describe one thing a user does from start to finish:
- "A customer finds a class, books a spot and pays."
- "A studio owner sets the weekly schedule and prices."
- "A customer cancels and gets a credit according to the studio's policy."
- "A studio owner sees who is coming to tonight's class."
These sentences are what a team estimates from. They are far more useful than a feature list because they show what matters and in what order.
4. What the first version must prove
The single outcome you will measure after launch, and the number. "Twenty studios each taking ten bookings a week through the app within three months." This lets the team suggest what to cut and what to keep.
5. Platforms and audience
Where your users are: iPhone, Android, desktop browser, tablet in a shop. If you do not know, say so and describe the users. The team will recommend.
6. Connections to other systems
Anything the product must talk to: a payment provider, an accounting package, a calendar, an existing website, a hardware device, a supplier's system. Name them. Integrations are the most common source of surprise cost and this section prevents it.
7. Content, brand and design assets
Do you have a logo, brand colours, photography, written content? Do you need the team to produce them? Both are fine. Unstated assumptions here cause delays.
8. Constraints
Budget range, target launch date and why, legal or regulatory requirements, languages and currencies, accessibility needs. A budget range is not a weakness. It lets the team scope honestly instead of guessing what you can afford.
9. What is explicitly out of scope
The features you have decided to leave for later. Writing them down proves you have made the decision and stops them creeping back in during estimation.
10. Examples and references
Two or three products you admire and what specifically you like about them. This communicates taste faster than any description.
What should you leave out?
- Technology choices. Unless you have a hard constraint, let the team recommend. A brief that specifies a framework it does not need narrows your options for no benefit.
- Detailed screen designs. Sketches are welcome as illustration. Finished designs before scoping lock in assumptions.
- Every feature you can imagine. The long list belongs in an appendix titled "later". The brief is about the first release.
- Marketing language. The team needs facts, not the pitch.
How long should it be?
Two to four pages. If it is longer, the user journeys section has probably turned into a feature list. If it is shorter, the problem and user section is probably missing.
Brief checklist
- One-line summary
- Problem and users, in their words
- Five to ten user journeys as plain sentences
- The outcome and number the first version must hit
- Platforms, or a description of where users are
- Systems to connect to
- Assets you have and assets you need
- Budget range, date, legal constraints
- What is out of scope
- Two or three reference products
What happens after you send it?
A good team will come back with questions, not a price. Expect a call that goes through the user journeys one by one, challenges a few, and asks what happens in the awkward cases: refunds, no-shows, a studio with two locations. That conversation is the start of discovery, and the quality of the questions tells you a lot about the team. When we receive a brief like this at 7L, the discovery phase is shorter, the quote is tighter and the first release is closer to what the founder actually needed. Send us yours and we will tell you what is missing.
Frequently asked questions
Should I send the same brief to several companies?
Yes. A consistent brief is the only way to compare quotes fairly. Ask each company what they excluded and what assumptions they made, and compare those before comparing totals.
Do I need a non-disclosure agreement before sharing a brief?
It is reasonable to ask for one and most professional companies will sign a simple mutual NDA without fuss. Do not let the NDA process delay the conversation by weeks. The brief rarely contains anything a competitor could use.
What if I do not know which platforms I need?
Describe your users and where they are, and let the team recommend. A wrong platform choice in the brief costs more than an honest question.
How do I state a budget without being overcharged?
Give a range and say what it must include. A team that scopes to your range is doing its job. A team that quotes exactly your maximum without explaining what you get for it is a warning sign.
Can 7L help me write the brief?
Yes. Our discovery phase starts from whatever you have, even a conversation, and produces the scoped first release and road map that a brief is meant to lead to.