A spec that survives
contact.
Most builds go wrong before a line of code — in a brief that skips the hard parts. This is the template we scope from: the problem, the users, what it must do, and just as importantly what it won’t. Fill it in below, keep it, and take it to any team. It’s yours — no email needed to copy or download.
What a good brief contains
A brief is not a specification and it is not a wish list. It is the document that lets someone experienced tell you something you don’t want to hear before it becomes expensive. These are the seven sections that make that possible.
The problem
Not the solution you have in mind — the problem underneath it. Who feels it, how often, and what it currently costs them in time, money or errors. A brief that opens with "we need an app" has skipped the only part an engineer can push back on.
Who it’s for
The actual humans, described honestly: how technical they are, what device they hold, whether they are at a desk or on a warehouse floor in gloves. This single section quietly decides half the technical architecture.
What it must do
The handful of things that have to work for the thing to be worth shipping at all. Five bullets is usually right; twenty means the priorities have not been decided yet, which is a decision you do not want a developer making for you by accident.
Out of scope — for now
The most valuable section in any brief, and the one almost everyone omits. Writing down what you are deliberately not building this time is what stops a three-month build becoming a nine-month one, and it gives everyone permission to say no later.
What success looks like
How you will know it worked, ideally as a number: a time that drops, an error rate that falls, a conversion that rises. "Users love it" cannot be built toward. A measurable target lets an engineer make trade-offs in your favour without asking.
Constraints
The deadline and what is attached to it, the rough budget band, systems it must integrate with, any compliance or data-residency requirements, and technology you are committed to. Constraints are not bad news — they are what makes an estimate real.
Open questions
What you genuinely do not know yet. Listing your uncertainties is a strength: it tells whoever reads this where their experience is most useful, and it stops them quietly assuming an answer you never gave.
Why briefs fail
We read a lot of briefs, including the ones behind builds that later needed rescuing. They fail in three recognisable ways.
It describes a solution
The brief specifies screens, features and a tech stack, but never the problem. Nobody can tell you that two thirds of it is unnecessary, because the reasoning was never written down — so you pay to build all of it.
Everything is in scope
No non-goals, no priorities, forty features of equal weight. The build has no natural shape, the estimate is a guess, and the first hard week becomes an argument about what actually matters.
Success is undefined
Without a measurable outcome, every trade-off gets resolved on taste rather than evidence — and the finished product cannot be judged, only argued about.
Common questions
Do I have to send this to you?
No, and it is genuinely useful if you never do. Copy or download it with no email required and take it to any team — the point of a good brief is that it makes every quote you receive comparable. Sending it to us is one option, not the price of admission.
How long should a brief be?
Two pages beats twenty. What matters is that the hard sections are answered rather than padded: the problem, the non-goals, and what success looks like. If those three are honest, an experienced team can scope from the rest.
What if I don’t know the technical details?
Then leave them out — that is the correct answer, not a gap. Choosing the stack is the job of whoever you hire. Your job is the problem, the users, the constraints and the outcome. A brief that guesses at architecture usually guesses wrong and anchors everyone to it.
Can I use this to get quotes from other agencies?
Please do. A consistent brief is the only way to compare proposals fairly, and it exposes the teams that answer a different question from the one you asked. We would rather be judged against a good brief than win by being the only one who understood it.
Is my brief stored anywhere?
Not unless you send it. The template runs in your browser and nothing is transmitted while you type — copy and download happen locally. Only pressing send transmits anything, and then it goes to Harley and Jonathan directly.
Brief written?
Let’s scope it.
Send it to us and it goes straight to Harley and Jonathan — a real reply within 24 hours, including an honest no if we’re not the right fit for it.
Is your build in trouble? → · What we do → · Project rescue →