Learning how to explain your app idea to a developer is the difference between a quote you trust and a quote that's really a guess. Most people freeze up here, because they assume the explanation has to be technical. It doesn't. The best briefs are written in plain English by the person who understands the problem best, you.
Here's the part that surprises people: the brief is the cheapest place to save money on the entire project. Every question you answer before anyone starts is a question nobody has to stop and ask later, and stopping is what makes builds slow and expensive.
This post covers what to include, what to leave out, the exact words that quietly inflate quotes, and how to write a useful brief even when you're not yet sure what you want.
Why most briefs get a guess instead of a quote
When a developer reads a vague brief, they don't refuse to quote. They quote for the worst reasonable version of what you wrote.
That's not cynicism, it's survival. If your brief says "users can book appointments" and doesn't mention cancellations, the developer has to decide: price it without cancellations and risk an argument later, or price it with cancellations and look expensive next to someone who didn't. Some pad the number. Some quote low and rely on charging for changes. Neither is what you want.
This is most of the reason app development quotes vary so much for what sounds like the same app. The spread usually isn't three different prices for one thing. It's three different guesses about what the thing is.
A clear brief collapses that spread. You'll notice it immediately, because the quotes start arriving close together.
Explain behaviour, not technology
You don't need to say "use a Postgres database with a REST API." You need to say what should happen: "a customer can save their favourite items and see them next time they log in." That single sentence tells an engineer they need accounts, storage, and a way to keep people logged in, without you naming any of it.
Focus on who does what, and what they see afterwards. Behaviour is something you're an expert in. Technology is the developer's job.
The test for any line in your brief: could you check whether it's true by using the finished app? "Customers can reset their password by email" passes, because you could try it. "The app is fast and modern" fails, because nobody can agree when it's done.
What you write, and what a developer has to guess
The gap between these two columns is where quotes go wrong. Every row is a real pattern that shows up in briefs constantly.
| What you write | What they have to guess | What to write instead |
|---|---|---|
| "Users can log in" | Email, Google, phone? Password resets? | "Users log in with an email and password, and can reset it by email" |
| "A simple booking system" | Who cancels? Double bookings? Refunds? | "Customers pick a free slot and get an email. They can cancel up to 24 hours before" |
| "Like Uber, but for X" | Which of Uber's hundreds of features? | "Drivers see nearby jobs, accept one, and the customer watches them approach on a map" |
| "An admin panel" | Which records? Which permissions? | "Staff see today's bookings, mark them complete, and can issue a refund" |
| "Users have profiles" | Which fields? Public or private? Photos? | "Each user has a name, photo and bio, visible to anyone with the link" |
Notice that the right-hand column isn't longer or more technical. It's just decided. That's the whole skill.
Name the edges
Where projects go over budget is almost always the edges, the "oh, and also" moments discovered halfway through. You can prevent most of them by thinking through a few questions up front:
- Who's allowed to do what? (Customers, staff, admins.)
- What happens when something goes wrong? (A payment fails, a booking clashes.)
- What has to connect to the outside world? (Payments, maps, email, calendars.)
You don't need the answers to be technical. You just need to raise them, so they're scoped instead of discovered.
Two more edges worth naming, because they're expensive when they arrive late. What happens on the very first screen when there's no data yet? An empty app is a real screen somebody has to design. And who can delete things, and what happens to everything attached? Deleting a customer who has ten bookings is a decision, not a button.
Turn your idea into a brief
Answer a few plain-English questions and get an itemized plan you can hand straight to a developer or agency.
Get your build planHow to explain your app idea when you're not sure yet
Most people wait until they feel certain. You'll never feel certain, so brief the uncertainty instead. It's completely normal and developers handle it well when you're upfront.
Mark the decided and the undecided. Two lists. "Settled: customers pay by card at booking. Open: whether staff can take phone bookings too." An honest open list gets priced as a range. A hidden one gets discovered mid-build at the worst possible moment.
Give the reason, not just the feature. If you say what a feature is for, a good developer will often propose something simpler that achieves the same thing. You can't get that help if you only hand over the what.
Say what must be true on day one. Everything else can be later, and being explicit about that is the single biggest lever on the price. It's the same discipline as deciding what to build first, and it routinely halves a first version.
Rank, don't just list. If you number the features by importance, a developer can tell you where the budget runs out. An unranked list gets cut by someone who doesn't know your business.
The words that quietly cost you money
Four words to strike out of any brief. Each one hides a decision.
"Simple." Nobody has ever agreed on what it means. A simple booking system is between two weeks and six months of work depending on answers you haven't given.
"Just." As in "it just needs to send them an email." The word "just" almost always sits in front of the most expensive item in the sentence.
"Etc." The list after your examples is the part being priced. If you end a list with "etc.", you've asked someone to invent scope and then bill you for it.
"Obviously." If it were obvious it would be in the brief. This one usually appears in the argument afterwards rather than in the document.
Replace all four with a number, a name, or a sentence you could test on the finished app.
Bring a plan, not just a paragraph
A paragraph describing your idea is a fine start. An itemized plan, broken into modules, grouped into phases, with each part explained, is what actually gets you an accurate quote. It shows the engineer you've thought it through, and it gives them a shared document to price against line by line.
That's the whole point of a build plan: it lets a non-technical founder and a senior engineer look at the exact same thing and mean the exact same thing by it.
If you'd rather work from a structure than a blank page, the seven sections in an app requirements document are the longer form of exactly this, and you can fill them in over an evening.
The questions you'll get back, and what they mean
A good developer answers a brief with questions. Here's what the common ones are really asking, so you can answer the question underneath.
"Who are the different types of user?" They're working out how many separate sets of screens and permissions they have to build. This is one of the biggest cost drivers in any app, so be precise. Three user types is closer to three times the work than to one.
"What happens if two people do this at the same time?" Booking the same slot, buying the last item. They need a rule from you, because there's no technical default that's right for every business.
"Where does this information come from?" If your app shows prices, stock or availability, somebody has to keep that current. Say who, and how often.
"Does it need to work offline?" Nearly always the answer is no, and saying so plainly saves real money. If it's yes, say it early, because it changes how the whole app gets built.
"What does done look like for version one?" They're asking for your launch criteria. Have an answer, even a rough one, or the project has no finish line and every extra week feels reasonable.
If you get none of these questions back, be a little wary. It usually means nobody read the brief closely, and the quote that follows is a guess in a confident font.
Write it this week, badly, then fix it
The best brief you can write today beats the perfect one you write next month, because a real developer's questions will improve it faster than more thinking will. Write two pages. Send it. Let the questions tell you what was missing.
And keep the answers, because the questions you get asked are the brief you should have written.
Get an itemized build plan: answer a few plain-English questions and get your idea back as modules and phases with an estimated total. Hand it straight over, and let the conversation start from a document instead of a guess.
Common questions
How do I brief a developer if I'm not technical?
Describe behaviour, not technology. Say what each person can do and what they see afterwards, in ordinary sentences. You are the expert on the problem and the developer is the expert on the solution, so your job is to be precise about the first thing and to leave the second one alone. A brief that says nothing about databases and everything about what users can do is a good brief.
What should a brief for an app include?
Five things: who the users are and what each type is allowed to do, the main thing someone comes to the app to accomplish, what happens when things go wrong, anything it has to connect to like payments or email, and which parts are version one rather than later. Everything else is optional. Those five decide almost the whole price.
How long should a brief be?
One to three pages is plenty for a first version, and shorter beats longer if it is specific. A developer reading your brief is looking for decisions, not description. Two pages of clear answers gets a better quote than twenty pages of context, because the twenty pages still leave them guessing about the things that cost money.
Why do developers keep asking me questions about my brief?
Because every unanswered question is a risk they have to price. If they cannot tell whether customers can cancel a booking, they either ask you or assume, and assuming is what makes quotes expensive and wrong. Questions early are a good sign. It means someone is trying to price the app you actually want rather than the one they imagined.
Should I say how I want the app built?
No, and it usually costs you money. Naming specific technology filters out developers who would have chosen better tools for your app, and it commits you to a decision you are not best placed to make. Describe what the app must do and let each developer propose how. If their proposal includes words you do not recognise, ask them to explain it in plain English.
Get a build plan for your idea
Describe what you want to build and get a clear, itemized plan in a couple of minutes.
Get your build plan
