How to write an app brief before you talk to developers

Why a short brief beats a long specification

A long specification tries to answer every question before anyone has tried the product. It usually describes features in detail and the problem barely at all. A good brief does the opposite: it is clear about the problem, the people and the first version, and honest about what is still unknown. Aim for two to five pages. If it grows longer, you are probably writing version three.

Write it in plain language, as if explaining the product to a smart friend who does not know your industry. Avoid naming technologies unless you have a real reason, such as an existing system the team already uses. Developers will propose the stack; your job is to make the problem, the people and the priorities impossible to misread.

1. The problem, in one paragraph

Describe the problem as it exists today, without mentioning the app. Who has it, how often, how they deal with it now and what it costs them in time, money or mistakes. If you cannot write this paragraph, the brief is not ready, and no developer can fix that for you.

2. Users and roles

List every kind of person who will use the product and what each one needs to do. Most business software has more roles than founders expect: an admin, staff with different permissions, clients or patients, sometimes a partner or an accountant who only reads. For each role, write who they are, what they do in the app and what they must never see.

3. The one job of version one

Version one should do one job well, for one main user. Write it as a single sentence: a clinic coordinator can see every new enquiry and reply from one screen, or a client can book and pay for a session without calling. Everything in the first version should serve that sentence. Everything that does not goes on a later list.

Keep that later list. It is not a graveyard for ideas; it is the start of your roadmap. Once real people use version one, you will know which of those ideas matter, and in which order.

If version one has three main jobs, it has none. Pick the one that would make the product worth using tomorrow.

4. Core flows, screen by screen

Walk through the main paths a user takes, step by step, as a list of screens. You do not need design skills; plain words or rough sketches are enough. For example:

Sign up: email and password, confirm the email, choose the company name.
Dashboard: the list of open requests, newest first, with a filter by status.
Request page: details, a reply box, a status button, the history of changes.
Settings: invite a team member, choose their role, remove access.

Write each flow from the user's point of view, including what happens when something goes wrong: a wrong password, an empty list, a payment that fails.

5. What is out of version one

This is the most useful section of the brief and the one most often missing. List what you have decided not to build yet: the mobile app, a second language, reports, integrations, an AI feature. Writing it down protects your budget and timeline, and tells developers you have made choices rather than left gaps.

6. Data and integrations

List the main information the product stores, such as clients, appointments, invoices and files, and where it comes from today. Note any existing data to import, and every outside service the product must connect to: payments, email, WhatsApp, calendars, accounting software. Mention any rules about personal or sensitive data, and where it must be stored.

7. Success measures and who decides

Say how you will know version one is working, in terms you can measure with real users: sign-ups, active accounts, requests handled, time saved on a task. These are not targets to promise; they are what you will measure together once it is live.

Then name who decides. One person should approve scope, designs and changes, with one backup. Projects slow down when decisions wait for a committee or change depending on who was in the last meeting.

Why a Discovery Sprint beats a fixed quote on a vague brief

Even a good brief leaves open questions. When the brief is still vague, any fixed quote for the full build is a guess: either padded to cover the unknowns or too low and followed by change requests. A short Discovery Sprint of two to three weeks turns the brief into a working first version you can click through and test, with a fixed quote for the sprint itself. You then decide on the full build with evidence, and the sprint fee is credited to it if you continue.

We have made a free app brief template that follows the structure of this article, with questions under each section and an example filled in. Download it below, fill it in at your own pace, and send it to us when you are ready. We read every brief, reply within one business day, and tell you plainly whether a Discovery Sprint or a direct build makes more sense.

A working MVP in 2–3 weeks, not slides.Book a 30-minute scope call