How to write an app brief that gets you a real number

Say eight things, and say them specifically. The same app described in two sentences came back at $13,000 – $25,000. Described properly it came back at $31,000 – $44,000. The second number isn’t a bigger project. It’s the same one with the rest of it written down.

$13,000 – $25,000: The app, described in two sentences
$31,000 – $44,000: The same app, described properly
$18,500: Half the price, sitting in the writer’s head

Written by

WhatWillMyAppCost

We build the estimator this site runs on, and we design and build custom mobile and web software for a living. Every figure below is the estimator’s own output, except the published vendor prices, which are read off each company’s own page and dated.

You’ve got an idea and you need a number for it. So you write a paragraph, send it to three companies, and get back three answers that don’t resemble each other. That isn’t a mystery about the companies. It’s what happens when a paragraph leaves most of the eight things below unsaid and each reader fills them in differently.

Below are the eight things, what each one is worth in dollars on a real build, what happens to the number when you leave one out, what happens when you say it loosely instead, what to write down about the parts you honestly don’t know, and how long the whole thing needs to be.

What goes in an app brief?

Eight things. None of them are technical, all of them are things you already know, and every one of them moves the price.

What it’s for, in one sentence about your business. “Our front desk does intake on paper and somebody retypes it that evening.”
Who uses it, and how many different kinds of person. Not headcount. Kinds.
What each of those people does with it, in the order they do it.
What it runs on. Phones, a tablet by the door, a computer in the office, or some mix of the three.
What already exists. Drawn screens, somewhere your data already lives that this would plug into, records sitting in an old system that have to come across.
What it has to talk to. Name the product and the version if you know them.
Where it gets used. A basement, a loading dock, a waiting room, somebody’s kitchen.
What you don’t know yet. Written down as a question rather than left out.

Every one of those maps onto something the estimator prices. The brief at the foot of this page is an example of all eight in just over a hundred words, and every figure below comes from running it.

What does leaving something out actually cost?

About $18,500 on this one, and it goes the direction nobody expects. The short description didn’t get a smaller number because the app got smaller. It got a smaller number because most of the app went unmentioned.

$13,000 – $25,000: The two-sentence version
$31,000 – $44,000: The same app with all eight things said

The short version reads: “We want a tablet app for signing people in. Our staff should be able to see what came in.” Both descriptions are of the same thing, which is a tablet at a front desk that takes somebody’s details, photographs their ID and the paperwork they brought, files all of it against their record and gives staff a web page showing the day. The short one mentions the tablet and the signing in. Everything else stayed in the writer’s head.

The same app, written two ways, came back at $13,000 – $25,000 and $31,000 – $44,000. The second one is the price. The first one is a shorter description with the same project still sitting behind it, and it’s the number that gets remembered.

Which is why a low first number is worth less than it looks. Somebody priced what you said. The rest of the app arrives later, in a conversation that starts with “I assumed that was obvious”, and by then there’s a figure in your head that everything else gets compared to.

What is each sentence worth?

Between $2,500 and $13,500, on a build of $31,000 – $44,000. These are the same figures the estimator produces when the sentence is there and when it isn’t.

“And the office needs to run it, not just look at it”: $13,000, taking the build to $42,000 – $59,000. The short sentence with the biggest price on it, and [what the office half of a build actually contains](/guides/field-service-app-cost) is the long version.
“It has to work when the wifi drops”: $13,500, taking it to $42,000 – $60,000. The most expensive sentence on the list, and one of the easiest to leave out because it only comes up when it fails.
“Three kinds of user, not two”: $6,000, taking it to $36,000 – $51,000. Each new kind of person is another set of screens and another set of permissions to test.
“A separate app for iPhone and another for Android”: $8,500, taking it to $38,000 – $54,000. Say which devices people carry and let whoever prices it choose how to build, unless you have a reason of your own.
“The designs are already drawn”: $4,500 off, bringing it to $27,000 – $39,000. Worth saying precisely: finished screens, brand colors only, or nothing at all are three different answers with three different prices.
“Something already works behind it”: $7,500 off, bringing it to $25,000 – $35,000. The largest saving available in a single sentence, and the one most often assumed rather than stated.

Naming the other system you have to connect to is the small one, about $2,500. It’s still worth writing down, because which product and which version decides whether that figure holds or triples, and your bookkeeper can answer both in a phone call. The wifi line is the one to be most careful with, since holding work on the device and getting it back are two separate jobs.

Why does a loose description get a wider number, not a bigger one?

Because not knowing what you want doesn’t make the work cost more. It makes the answer less precise, and those are different claims. Name every feature above but describe them loosely, and the middle of the estimate doesn’t move at all. The range around it nearly doubles, from $13,000 end to end to $23,000.

$31,000 – $44,000: Named and described specifically
$26,000 – $49,000: Named and described loosely

Not mentioning something: Moves the number down and leaves it wrong. Nobody prices what nobody said.
Mentioning it vaguely: Leaves the number where it was and widens the range around it. Honest, and less useful to you than it could be, because a range that wide isn’t something anybody can plan against.

So the work of a brief is two jobs, not one. Cover everything, then say each thing precisely enough that the range is tight enough to plan against. The first job is worth more money. The second is what makes a fixed budget safe.

What do you do about the parts you don’t know?

Write them down as questions. “I don’t know whether our accounting software can be connected to” is a real line in a brief, and a good one. Written down, it gets priced as something nobody knows yet. Left out, it gets quietly assumed to be easy.

Say which version of the other system you run, or say that nobody knows. Both are useful. Silence isn’t.
Say whether the data that has to move across is clean, or whether it’s eleven years of a spreadsheet nobody has looked at.
Say who on your side can answer a question, and how fast. A week of waiting on an answer costs more than most features.
Say what you’re unsure about in the idea itself. The parts you might be wrong about are the parts worth building first.

That is a different thing from the vagueness in the section above, even though both widen the number. A range that is wide because nobody was specific is a range nobody can act on. A range that is wide because you wrote down four questions is a list of things to go find out, and the answers narrow it. A brief with four honest unknowns in it beats one that quietly assumes the best case on all four, and it gets you a far more useful first conversation.

How long should a brief be?

A page. Here is the one that produced every figure above, written the way somebody would say it out loud, with no headings and no formatting.

Our front desk still does intake on paper and then somebody types it in again that evening. We want a tablet by the door instead. The person signs in, fills in their details, we take a photo of their ID and any paperwork they brought, and it comes out the other end as a PDF filed against their record. Staff need a web page showing who came in today. It probably has to hand off to the practice management software we already run, but honestly nobody here knows whether that can be connected to. Two kinds of user: the people filling it in, and our staff. We have brand colors. Nothing else is drawn, and there is no system behind any of this yet, so that needs building too.

That is 129 words and it covers all eight points, including the one nobody knows the answer to. Run it through the estimator, then cut it back to two sentences and watch what the number does.

Longer is not better past that point. Coverage is what counts: eight things said plainly beats four pages of background about your industry. If you find yourself explaining what your business does for three paragraphs, the first sentence isn’t doing its job yet.

And write it once, then send the same one to everybody. Three companies reading the same brief is a comparison. Three companies reading three different conversations is not one, and that’s the most common reason the numbers come back looking unrelated. What a $50,000 budget buys prices one build against that number and lists the four things that push it over.

A brief covers eight things: what it’s for, who uses it, what they do, what it runs on, what you already have, what it connects to, where it gets used, and what you don’t know. Said properly, the tablet app above prices at $31,000 – $44,000. Said in two sentences, the same app prices at $13,000 – $25,000.

The gap is the part you left in your head. Getting it onto the page is an hour of work, and it’s the difference between a number you can plan against and a number you’ll spend the next six months revising.

FAQ

Questions about writing a brief

What should be included in an app development brief?

What the app is for in one sentence about your business, who uses it and how many kinds of person, what each of them does with it, what it runs on, what already exists on your side, what it has to connect to, the conditions it gets used in, and whatever you genuinely don’t know yet. Eight things, none of them technical.

How long should an app brief be?

About a page. The worked example in this guide runs just over a hundred words and covers all eight points, including the one its writer doesn’t know the answer to. Coverage matters more than length: a short brief saying all eight things gets a better number than four pages of background that skip two of them.

Do I need to know what features I want before getting a quote?

You need to describe what people will do with it, which isn’t the same thing. Features are a translation of that, and somebody else can do the translating. What nobody else can supply is who uses it, what they do, and where they do it. Leave those out and the estimate comes back low: a two-sentence description of a tablet check-in app priced at $13,000 – $25,000, against $31,000 – $44,000 once the same app was fully described.

Why do different companies give different quotes for the same app?

Usually because the description left decisions open and each reader closed them differently. One assumed the office needs its own web portal and one didn’t. One assumed the designs exist. Those two assumptions alone are worth thousands of dollars in either direction. The fix is on your side of the table: send everybody the same brief, with the assumptions written into it.

What is most often left out of an app brief?

Three things. What the staff side needs to do, worth about $13,000 on a $31,000 – $44,000 build. Whether it has to keep working without a connection, worth $13,500. And how much already works behind it, worth $7,500 in the other direction. The third is the one people assume is obvious and never say.

Should I write a technical specification or a business brief?

A business brief. Describing the technology narrows the options before anybody has looked at the problem, and it’s the fastest way to pay for a decision that turned out to be wrong. Describe what people do and what it has to work with. If you have a real constraint, like a system you can’t replace, say that as a constraint.

Can I just send a list of features?

It gets you a number, and it’s a worse number than a paragraph about how the work happens. A feature list says “photo capture”. A paragraph says the photo gets taken in a waiting room by somebody holding a clipboard, which decides how the screen works and how long it takes to build. Send both if you have both.

What if I don’t know whether I need iPhone, Android or both?

Say what people carry and let that answer it. If they’re your own staff on company phones, name the phone: building for one instead of two is a real saving. If it’s a mix, say so and let whoever prices it decide how to build, because that choice is worth thousands and shouldn’t be made by default in a brief. [What a $50,000 budget buys](/guides/what-50000-buys) has the figures on that decision.