Writing an App Brief a Developer Can Price

You describe your app idea to three developers over the phone. A week later the quotes arrive, and they are so far apart they could be for three different projects. In a sense, they are. Each developer filled the gaps in your idea with their own guesses, and priced the guesses.

The spread is not proof that someone is overcharging. It is proof the idea was not written down. A short brief closes the gaps before anyone guesses, so the quotes you get back are for the same thing and you can compare them.

Why quotes drift apart

A developer pricing a project is really pricing risk. Every question they cannot answer from what you sent becomes either an assumption or a cushion. One assumes logins are simple; another assumes they connect to your existing customer records. One assumes iPhone only; another assumes iPhone, Android and an admin website. None of them is wrong. They are just answering different questions.

The brief’s job is to answer those questions once, in writing, for everyone.

Start with the problem, not the screens

Open with two or three plain sentences about what is not working today. “Customers call to book, and the front desk spends half the morning on the phone.” “Our drivers track deliveries on paper and the office never knows where anyone is.”

A good developer may find a smaller, cheaper way to solve the problem than the app you pictured, and they can only do that if they know the problem. It is the same rule we give for a marketing brief your agency can use: describe the problem clearly and let the people you hire propose the answer.

If you are not yet sure an app is the answer at all, start with should your business have its own app before you write a brief.

Name every kind of user

List each type of person who will touch the app and what they need to do. Customers book and pay. Staff see the day’s schedule. The manager changes prices and runs reports. You approve refunds.

Each new type of user usually means new screens and new permissions, so this list drives the price more than almost anything else. The person who uploads the weekly menu is a user too.

Describe what each user does, step by step

For each type of user, write their main tasks as short, numbered steps in plain language:

1. Customer opens the app and picks a service.
2. Customer sees open times for the next two weeks and picks one.
3. Customer pays a deposit.
4. Customer gets a confirmation and a reminder the day before.

You do not need wireframes. A few short walkthroughs tell a developer more than a page of words like “simple” or “modern.”

Split must-haves from later

Go through every feature and mark it one of two ways: needed on launch day, or can wait. Be strict. An app that does a few things well on launch day beats one that does everything late.

This also gives you a lever when the quotes come in. If the number is higher than you planned, you and the developer can talk about what moves to the second list, instead of starting over.

List what it has to connect to

This is where hidden cost lives. Write down every system the app needs to talk to and what moves between them:

• Your booking or scheduling system
• Payments, and which processor you use today
• Your customer records or point of sale
• Accounting software
• Email or text messaging
• Anything your team keeps in spreadsheets that the app will need

Say who owns each account and whether you can get access. An integration with a well-documented system is routine. An integration with an old system nobody has the password for is a project of its own.

Say where it runs

iPhone, Android, a web app, or some mix, and whether staff need a separate admin screen on a computer. If you do not know, say so and say who your users are; that is a fair question for the developer to answer. Just do not leave it blank, or each quote will assume something different.

Name the limits

Every honest quote needs these:

• Budget, as a range. You will not get a better price by hiding it; you will get proposals you cannot afford.
• The date that matters, and why. A season, an event, a contract. “As soon as possible” is not a date.
• Rules you have to follow. Customer data you collect, payments, anything your industry regulates.
• Who decides. The one person who signs off on designs and on launch.

Ask about life after launch

Phones update, app store rules change, and something will break at some point. Ask each developer to price support after launch separately, and to say what it covers: fixes, updates for new phone software, hosting, monitoring. A quote that stops at launch day is only part of the cost of owning an app.

Before you send it

Read the brief back and ask:

• Could a stranger explain the problem after reading the first paragraph?
• Is every type of user listed, including staff and admins?
• Is every feature marked launch day or later?
• Is every outside system named, with an owner?
• Did we give a budget range and a real date?
• Did we ask for support after launch to be priced on its own?

Send the same brief to every developer and ask each to list their assumptions with the quote. The assumptions tell you as much as the price.

Where we come in

Our software development team builds web, mobile and internal applications in-house, and every project starts with discovery: stakeholder interviews, requirements and scope, solution design and success metrics. We support the software after launch, and we can audit and take over an existing project. For iPhone and Android apps, our mobile application development team handles design, build and the app store launch.

If you have an app idea and a blank page, book a call and we will help you turn it into a brief.