An app brief developers can actually price

What a brief is for

A brief is a short document that answers the questions a developer needs answered before they can give you a price. It is not a specification, a pitch deck or a list of features. It is a one-page statement of who the product is for, the problem it solves, what must work first, and what is deliberately left out, written so that a stranger can understand it without a call.

Its main value is to you. Writing it forces decisions that are otherwise postponed until they are expensive, and it gives you something to compare vendors against. Its second value is to the developer, who can respond with a real estimate, with assumptions, instead of a guess.

The tool above lets you fill it in section by section and shows the finished document alongside, with a copy button and a plain-text download. Nothing you type is stored on a server.

Section by section: name, who and problem

The working name is for convenience. It does not need to be final. It makes the document feel like it is about a real thing and gives people something to call it.

Who is it for? Write one sentence about the user and where they are. 'Small shop owners in tier-two cities who take orders over WhatsApp' is a user. 'Everyone' is not. A specific user lets a developer make a hundred small design decisions correctly without asking you.

What problem does it solve? Describe what they do today and what hurts. People often skip this and describe the solution instead. The problem is more useful, because a developer might know a better solution than the one you have in mind.

Must-haves, and what is out

Three things that must work on day one. The limit of three is the point. If you cannot choose three, you have not decided what the product is. Write them as things a user can do, not as features: 'a customer can place an order and pay', not 'checkout module'.

What is deliberately not in version one. This section is as important as the previous. It shows the developer where the edges are and prevents the quiet assumption that everything you have ever thought about is included. It also gives you a place to put the ideas you do not want to lose.

What you already have, integrations and constraints

List what exists: a brand, a logo, a website, a catalogue, customer data, an accounting system. Each reduces what has to be built and some constrain how the new thing must work.

List the integrations you know you need: payment, SMS, WhatsApp, maps, accounting software, an existing database. Each is its own piece of work and should be named. If you are unsure, write 'not sure' and ask the developer to advise.

Then constraints: launch date, budget range, platforms you must support, any compliance requirement such as handling health or financial data. Being honest about a budget range saves everyone's time. It lets the developer propose something that fits, instead of something that does not.

A good answer and a poor one, side by side

Poor, for the problem field: 'We need an app like the big food delivery apps.' It tells the developer almost nothing, and it invites a quote for something enormous.

Good: 'Eight small restaurants in our town take orders by phone and WhatsApp. They lose orders at busy times, and customers do not know when food will arrive. We want customers to order and pay in one place and the restaurant to see the queue.' It names the users, the pain and the shape of a solution, and a developer can see how large it is.

Poor, for must-haves: 'Login, profile, notifications, chat, reviews, offers, wallet, referrals.' Good: 'A customer can find a restaurant, order and pay. A restaurant can see and accept orders. The owner can see the day's totals.' The second is smaller and more useful, and it describes outcomes.

What to do with it once it is written

Send the same brief to two or three developers and ask for a short call and a written proposal. Compare the proposals using the same questions: what is included, what is not, what are the milestones, how are changes handled, who owns what.

Keep the brief and update it. As you learn, the document should change, and each change should be a deliberate decision. A brief that is revised in the open is the best protection against scope arguments.

If you want help turning a brief into a scope and a price, send it to me. I will tell you plainly what I would build first, what I would leave, and what it would cost.

What a developer will do with your brief

A developer reading a brief goes through it asking: what is the smallest thing that satisfies the must-haves? Which parts are routine and which are risky? What is missing that I need to ask? They build a rough picture of the screens, the data and the integrations, and from it the effort. If your brief is clear, that process takes an hour or two and produces a confident range. If it is vague, they pad the estimate to cover what they cannot see, or ask you many questions.

The risk list that a good developer returns is as valuable as the price. It names the parts of your idea that could be harder than they look, such as an integration with a system that has no documented interface, or a feature that depends on data you do not have. Treat that list as a gift. It is a cheap way of learning about problems before they are expensive.

Reviewing the document before you send it

Before you send the brief, read it as a stranger would. Does every sentence mean something specific? Could a developer who has never heard of your business tell what the product does? Are there any words like 'modern', 'user-friendly' or 'seamless' that carry no information? Remove them. Replace each with what it was meant to say.

Then ask a friend who is not in your business to read it and tell you, in their own words, what is being built. Their summary will show you what is unclear faster than any amount of rereading. If they describe something different from what you meant, the brief is not ready.

Questions people ask about briefs

Common mistakes in briefs

• Describing features instead of problems and users.
• Listing everything you can think of as a must-have.
• Leaving out the budget range and then being surprised by the quote.
• Not saying what already exists.
• Writing it to impress and not to inform.
• Treating it as final, rather than the start of a conversation.

A short, honest and specific brief beats a long, polished and vague one every time.