How to write an app brief

What is an app brief?

An app brief is a short document that explains what you want built and why. It is not a technical specification, and you do not need to know how apps are made to write one. Its job is to give a developer enough to understand your idea, ask sensible questions and propose a realistic plan.

A few pages is usually enough. Plain sentences work better than polished slides. Where something is undecided, say so: an honest “we don’t know yet” is more useful than a guess presented as a decision, because it tells the developer where to help.

Who the app is for

Start with people, not features. Describe the people who will use the app, in a few sentences each. What do they do today? Where are they when they open the app: at a desk, on a train, on the sofa with a remote in their hand? How comfortable are they with technology?

If there is more than one type of user, list each one. A booking app, for example, may have customers who book, staff who manage the bookings and an owner who wants reports. Each group needs different screens, and some may not need an app at all: a simple admin website is often enough for staff.

The problem it solves

Write the problem in one or two sentences, from the user’s point of view. “Customers have to phone us to check availability” is a problem. “We need an app” is not.

Then explain how people deal with the problem now: a spreadsheet, a competitor’s app, a phone call, a paper form. This tells the developer what your app has to beat, and it usually shows which parts matter most. If you have spoken to potential users, summarise what they told you, including anything that surprised you.

Must-have and nice-to-have features

List what the app needs to do. Write each item as something a person does, not as a technical term. “A customer can pay by card and gets a receipt by email” is clearer than “payments integration”, and it leaves the developer free to suggest the best way to do it.

Must-have features

These are the things without which the app is not worth releasing. Be strict. If the first version could launch without it, it is not a must-have.

Nice-to-have features

Everything else goes here: ideas for later, features competitors have, things that would be pleasant but are not essential. Keep this list. It shows where the product could go, and it helps the developer avoid early choices that would make those features hard to add later.

A simple test

For each feature, ask: “If this were missing on launch day, would the people we described still use the app?” If the answer is yes, move it to nice-to-have. Most first versions get better, and get finished sooner, when the must-have list is short.

Platforms: phone, tablet, TV and web

Say where people will use the app. Each platform adds design and build work, so it helps to know which matter most and which can wait.

• Phone: iPhone, Android or both. If you know most of your users have one or the other, say so.
• Tablet: whether the app needs a layout designed for the larger screen, or whether the phone version is enough at first.
• TV: Apple TV, Android TV and Google TV, Fire TV, Roku, Samsung and LG each work differently. TV apps are used from across the room with a remote, so they need their own design.
• Web: a website that explains and sells the app, a web version of the app itself, or an admin area for your team. These are different pieces of work, so name the ones you need.

If you are unsure, describe your users and the devices they own. A developer can recommend a sensible starting point from that.

Examples and references

Point to apps you admire and say what you like about each one: the sign-up, the way search works, the tone of the writing, the look. Do the same for apps you find frustrating. A screenshot with one sentence of explanation is worth more than a list of app names.

Include anything you already have: sketches on paper, a logo, brand colours, a domain name, an existing website, or the spreadsheet the app will replace. None of it needs to be finished. It gives the developer context and saves them guessing.

Budget and timeline

Budget

Many people leave the budget out because they worry it will be used against them. In practice, a range helps more than silence. The same idea can be built in very different ways, from a focused first version on one platform to a full product on every screen. Without a range, the developer has to guess which one you mean.

Think about money in three parts: building the first version, running it (hosting, app store accounts and any paid services the app relies on) and looking after it (updates, fixes and support). Running and looking after an app continue for as long as it is live, so plan for them from the start. If you genuinely do not know what is realistic, say so and ask for options at different levels.

Timeline

Separate dates that are fixed from dates that are hopes. A trade show, a season or a funding deadline is fixed. “As soon as possible” is not a date. If a date is fixed, say what must be ready by then: it may be a smaller first version, with the rest following after.

Allow for time on your side too. Reviewing designs, answering questions, testing early versions and preparing content such as text, images and prices all take time, and they often decide when an app can launch.

How you will measure success

Decide how you will know the app is working. Pick a few measures that link back to the problem you described: fewer phone calls, more bookings made without help, people coming back each week, or paying subscribers. You do not need targets yet, but you should know what you will look at.

This shapes the build. If repeat use matters, the app may need accounts and reminders. If sales matter, the payment steps deserve the most care. It also tells the developer what to measure from the first day.

What to send an app developer

Put everything in one document and send it with any files. A good brief covers:

• a one-paragraph summary of the idea
• who the app is for, and each type of user
• the problem, and how people solve it today
• must-have features, then nice-to-have features
• the platforms you need first, and the ones that can wait
• apps you like and dislike, with a sentence on each
• anything you already have: sketches, branding, content, an existing site
• your budget range and any fixed dates
• how you will measure success
• who makes decisions on your side, and how to reach them

Expect the brief to change. After the first conversation, update it with what you agreed. It becomes the reference everyone works from.