How to Write a One-Page Mobile App Brief a Developer Can Quote

You have an app idea, a number in your head, and three developers to talk to. You send each of them a paragraph and a phone call. Three weeks later you have three quotes that cannot be compared: one is four times another, and the third says it depends. The problem is usually not the developers. It is that nobody gave them the same thing to price.

A mobile app brief that fits on one page fixes most of this. Not a specification — a brief. One page, written by you, that says what the app does, who uses it, and what you will judge it by. Here is what belongs on it, what to keep off it, and an outline you can fill in this week.

Why a short mobile app brief gets better quotes than a long one

We read a lot of briefs. The ones that produce accurate quotes are almost never the longest. A thirty-page document written before anyone has built anything is mostly guesses, and the developer reading it has to work out which guesses are load-bearing. That takes hours. Most people do not do it. They skim, add margin for everything they did not read, and send you a range.

One page has the opposite effect. It is short enough that a developer will read every line, and short enough that you have to choose what matters. Anything you leave off is a decision you made on purpose, not something buried on page nineteen.

It is also a filter. Send the same page to three developers on the same day. The one who comes back with three sharp questions is worth more of your time than the one who quotes within the hour, and more than the one who insists on a full specification before saying anything at all.

A quote is only as precise as the brief it answers.

The eight things that belong on the page

Each of these takes one or two lines. If yours runs longer, you are writing a specification.

• What it does, in one sentence. Not the category. A delivery app tells a developer nothing. Restaurant owners take orders from customers and assign each one to one of their own riders tells them almost everything.

• Who uses it. List every type of user. Each type is roughly its own section of the app, so three user types is a much larger job than one. Customers, riders and restaurant staff are three.

• The screens you can already picture. Name five to ten: sign up, browse, cart, checkout, track order, order history. The number of screens is the best predictor of effort that a non-engineer can produce on their own.

• What it connects to. Payments and which provider, maps, SMS, an existing website, a spreadsheet you run today. Integrations are where estimates go wrong. Naming them moves that risk into the conversation instead of into the invoice.

• Platforms and the worst phone. Android only, or Android and iOS? What is the cheapest handset your customers actually carry, and do they have data all day? Must work on a cheap Android with patchy signal changes how the app is built. It should not surface in week six.

• Who keeps the data up to date. Who adds the restaurants, who changes the prices? If the answer is you, you need an admin panel, and an admin panel is often a third of the work. Founders leave this out more often than anything else on this list.

• Your real constraint. A date, a budget ceiling, or a monthly running cost. Pick the one that is actually binding and write it down. A good developer will design to a constraint. None of them can guess it.

• How you will know it worked. A few hundred orders a month by June, or our two office staff stop retyping orders into a spreadsheet. This is what tells a developer which corners are safe to cut.

What to leave off

• Technology choices. Unless you already run a system or a team that constrains it, do not name the framework or the database. You would be pricing a decision you have not made. Ask each developer what they would use and why — the answers compare better than the prices do.

• Features copied from a large competitor. The app you admire has hundreds of people behind it. Its referral scheme, its loyalty points and its in-app chat are not your version one, and listing them inflates every quote you get.

• Invented designs. If you do not have designs, write that you do not have designs. It is more useful than screens mocked up in a slide deck that nobody will follow.

• Anything marked phase two. It gets priced anyway, or it pulls attention away from the part you are actually buying. Keep that list, just keep it on a different page.

• An NDA before the first call. Reasonable later. Early on it only slows down the stage where you are comparing people, and most of what fits on a one-page brief is not the secret part anyway.

A one-page outline you can fill in

Copy these nine headings into a document and answer each in one or two lines. Where you do not know, write don't know — that is real information, and it gets you advice instead of padding.

• The app in one sentence — who does what, and where.

• Users — one line per type of user, with what they do.

• Screens — your best guess, five to ten, named.

• Connects to — payments, maps, SMS, an existing site or spreadsheet, or nothing.

• Devices and network — platforms, plus the worst phone and connection you must support.

• Who maintains the content — you, through an admin panel, or nobody because it is automatic.

• Constraint — the binding date, budget ceiling or monthly running cost.

• Success in six months — one thing you could measure.

• What we already have — designs, a website, a customer list, an existing spreadsheet, nothing.

Add a tenth line if it helps: the questions you want advice on. Developers tend to answer those for free, and the answers tell you who has done this before.

Reading the quotes that come back

• Compare scope before price. If one quote is half of another, it is usually half the app. Put the screen lists side by side and see which ones each developer assumed.

• Ask what is excluded. App store submission, the admin panel, hosting for the first year, and bug fixes after launch are the four things most often left out.

• Ask for milestones, not one number. Three or four payments, each tied to something you can open on your own phone and use.

• Prefer the quote with written assumptions. Assumptions are where change requests come from later. A slightly higher quote that lists them is usually cheaper than a lower one that does not.

What to do next

1. Set aside forty-five minutes and fill in the nine headings from memory. Do not research. The gaps are the point.

2. Send the same page to two or three developers on the same day, and ask for their questions before a number.

3. Score them on the questions they ask, not on how fast they reply.

4. Take the sharpest two and pay for a short scoping conversation if they offer one. It is the cheapest money you will spend on the project.

If you want a second opinion on the page before you send it, or a quote against it, talk to us. We build mobile apps and web platforms for founders and small companies, and we would rather ask the awkward questions now than in month three.