How to Write a Project Brief a Developer Can Actually Quote

Ask any developer about the worst project they ever worked on, and the story almost never starts with a technical problem. It starts with a brief. Or rather, the absence of one: a two-line email saying "we need an app like Uber but for X", three months of building toward a moving target, and a relationship that ended with both sides convinced the other was impossible.

Here is the strange economics of it: the project brief is the highest-leverage document in your entire project. It costs you two focused hours, no money, and no technical knowledge, and it influences everything: which developers reply to you, what they quote, how accurate those quotes are, and whether month three is spent shipping features or arguing about what was "obviously included". Two hours against tens of thousands of dollars. Nothing else in software has that ratio.

Yet almost nobody writes one, because they believe they cannot. "I'm not technical, I don't know how to spec an app." Good news: a brief is not a technical specification. Technical decisions are the developer's job. The brief's job is to transfer what is in your head, the problem, the users, the constraints, into theirs. You are the only person in the world qualified to write it.

This article is the exact template I wish every client would send me, with instructions for each section and the reasoning behind them.

Why quotes are useless without one

When a developer receives "we need a booking platform, what would that cost?", they are not pricing your project. They cannot. They are pricing their imagined version of your project, and every developer imagines something different. That is why three quotes for the "same" project come back at four, twenty and sixty thousand: they are quotes for three different imaginary products. You cannot compare them, and the winner is usually whoever imagined the least, which becomes your problem later, a dynamic I unpack in how to pay a developer without getting burned.

A written brief collapses the imagination gap. Everyone quotes the same product, quotes become comparable, and, as a delightful side effect, the quality of who replies changes. Serious developers triage inquiries constantly, and a clear brief signals a client who knows what they want, decides things, and will be good to work with. Vague briefs attract whoever is hungriest; clear ones attract whoever is good. I said the same thing from the hiring side in my founder's guide to hiring a developer: the brief is step one of hiring well.

The template

Eight sections. Aim for one to three pages total; past five pages, briefs stop being read and start being skimmed.

1. The business, in three sentences. Who you are, what you sell, who your customers are. Not marketing copy, orientation. Every downstream suggestion a developer makes is better when they know whether you are a dental clinic, a B2B logistics firm, or a creator with an audience.

2. The problem, in plain words. The single most important section, and the one people skip to get to features. What is happening today that should not be, or not happening that should? "Customers call to book appointments, we miss a third of the calls, and evenings are our highest-demand booking time" is a problem. "We need a booking app" is a solution you have pre-purchased, and possibly the wrong one. State the problem and let solutions compete; developers solve stated problems better than they decorate assumed solutions, and sometimes the right answer is smaller and cheaper than what you were about to commission.

3. The users. Who touches this system? Customers, your staff, an admin, a manager who only wants reports? A rough list with a sentence each. Feature lists routinely forget entire user types, usually the internal ones, and every forgotten user type is a surprise invoice later.

4. What version one must do. The feature list, with the discipline of three buckets: must have for launch, later (real, but not launch-blocking), and explicitly not doing (things a developer might reasonably assume you want; naming them prevents them being silently priced in, or silently promised). Keep must-haves brutally short. Every serious product you admire launched with a fraction of its current features; scope discipline is what launching feels like. Write features as outcomes, "a customer can book a slot and pay a deposit", not as screens or technologies.

5. What exists already. Current website, designs, a logo, a spreadsheet that is secretly the current system, a half-built codebase from a previous attempt, accounts you already own. All of it changes estimates, sometimes dramatically. A rescue of existing work is a different project from a green field, and pretending otherwise wastes everyone's first meeting; if your existing situation involves a vanished developer, I have a whole guide for that.

6. Constraints and connections. Deadlines with reasons ("before September, our trade show" beats "ASAP", which means nothing and signals panic). Systems it must talk to: your payment provider, your accounting software, your calendar. Compliance realities: health data, EU customers, minors. One line each is enough; these are exactly the items that turn "small project" into "medium project", and you want that discovered now, on paper, not in month two.

7. Success, measurably. Finish this sentence: "Six months after launch, this project has worked if…". Bookings up, calls down, hours saved weekly, first hundred paying users. This sentence quietly powers the best trade-offs later, because when a mid-project decision arises, "which option serves the success sentence" resolves arguments that "which option did we vaguely discuss in April" cannot.

8. Budget range and decision process. The section everyone wants to omit, fearing that naming a number means paying it. Here is what actually happens without it: developers guess, half of them guess wrong by 5x in either direction, the fits walk away, and the mismatches send proposals you cannot use. A range, "we have budgeted 10 to 20k for version one", filters honestly in both directions and invites the most useful sentence a good developer can say early: here is what fits inside that range, and here is what does not. Add who makes decisions (one name, ideally) and how fast you intend to move.

What to deliberately leave out

The stack. The database. The framework. The hosting. Unless you have a genuine constraint ("our team maintains it after handover and knows Python"), technology choices belong in the developer's response, not your brief, and prescribing them narrows your candidate pool for no benefit. You are hiring judgment; let candidates show it. The brief describes the destination; the route proposals are how you evaluate drivers.

Same for design mockups of every screen: nice if you have them (that is "what exists already"), never a prerequisite. Rough sketches or "make it feel like these two sites" is plenty for a brief.

How to use it once written

Send the same brief to every candidate; identical inputs make replies comparable, which was the point. Then grade the replies, and grade them on questions asked, not just prices returned. A developer who reads your brief and responds with three sharp questions and a suggestion to cut a feature from version one is showing you what working with them is like. A same-day fixed quote for the whole thing with no questions is showing you something too.

Expect, and welcome, the good ones challenging the brief. "Why is feature X a must-have when the success sentence is about bookings?" is the sound of the document doing its job: forcing the important arguments to happen on paper, at the cheapest possible moment, instead of in the codebase, at the most expensive one.

Then keep it alive. The brief becomes the reference point for milestone one, the thing scope changes are measured against ("this is new relative to the brief, here is what it changes"), and, six months after launch, the success sentence gets its answer. Total lifecycle cost: those original two hours, plus revisions when reality teaches you something.

The uncomfortable truth this document surfaces

One warning from experience: some people sit down to write section 2 and discover they cannot state the problem, or write section 7 and find no measurable success exists. That discovery feels like the template failing. It is the template succeeding. It just saved you the five-figure version of the same discovery. A project that cannot survive two hours of writing was never going to survive four months of building; sharpen the idea, then commission it.

If you write a brief with this template and want a professional read on it before you send it anywhere, send it to me. I will tell you what a developer would ask, what is missing, and roughly what bracket the must-have list lands in, and if the honest answer is "this is a WordPress site, you don't need someone like me", I have an article for that too. A well-briefed project is a pleasure to quote either way, and the fifteen minutes it takes me is the cheapest way I know to show you how I work.

Quick answers

How long should a project brief be? One to three pages. Long enough to cover the eight sections, short enough to be read rather than skimmed. Detail belongs in conversations the brief provokes.

Do I need to be technical to write one? No, and the brief is better if you resist trying. Problems, users, constraints and success are business knowledge, your home turf. Technology is the response, not the request.

Should I really share my budget? Share a range, and watch what it does: honest developers tell you what fits inside it, and mismatches self-select out before costing you meetings. Hiding it does not protect the number; it just delays the moment of comparison to a more expensive stage.

What if I don't know my requirements yet? Then say so in the brief; that is a legitimate project shape. Ask for a small paid discovery engagement first, a week or two producing exactly the missing sections. Do not let anyone fix-price the fog; that is how both sides lose.

Can AI write my brief for me? It can interview you into a solid draft, and that is genuinely useful. What it cannot supply is the content only you have: the real problem, honest constraints, the success number you would stake money on. Use AI as the scribe, never the source.