How to Brief a Developer So You Get What You Imagined

If you have ever opened a finished website and felt your stomach drop, you already know the sentence. That is not what I wanted. In most of those stories, the developer built exactly what was asked for. The problem was the asking.

The picture in your head was crisp. You could see the screens, the flow, the way a customer would glide through it. What landed in the developer's inbox was three paragraphs and a logo. Nobody can build the picture. They can only build the page.

The good news is that fixing this costs nothing, and it does not mean writing a longer document. A short honest brief beats a thick spec every time, because a spec lists everything and commits to nothing, while a brief makes the handful of decisions that actually shape the build. Here is how to write one.

Lead with the outcome

Most briefs open with a feature list. Booking system, customer accounts, admin dashboard, notifications. Features feel concrete, which is why people reach for them, but they describe the furniture when the developer needs to know what the house is for.

Open instead with one sentence about what becomes true once the thing exists. Take a physiotherapist who keeps losing patients in the gap between sessions. Her brief does not need to mention a database. It needs one line: a patient books the next appointment before they leave the table, and if they skip a week, they get a gentle nudge. Now every proposed feature can be held up against that sentence, and everyone can see which ones serve it.

Then name the one person this is for and the single thing they must be able to do. Not users. One person. Take a hardware store owner. Build it for the contractors who phone in the same fifty orders every Monday morning and you get one product. Build it for the weekend shoppers checking stock before they drive over and you get the opposite. Same store, same owner, opposite software. The brief that names the contractor and the Monday morning order is worth more than ten pages that name neither.

Show references, not adjectives

Design by adjective is how projects drift. Clean. Modern. Premium. Make it pop. Every one of those words means a different thing to every person who reads it, and your developer will fill the gap with their own taste, which may not be yours.

Send links instead. Two or three sites or apps you admire, each with a single line on why. I like how fast this loads. I like that the price sits on the first screen. I like that my mother could use this. A screenshot with a circle drawn around the part you mean beats a paragraph describing it, every single time.

What you dislike is just as useful, sometimes more. One example of a site that feels wrong to you, with a line on why, draws the edges of the territory. Taste is hard to describe and easy to point at, so point.

While you are at it, write down the things you believe are too obvious to mention. That orders come in by phone. That half your customers pay cash. That your busy season is December. You have lived inside your business for years. Your developer has lived inside it for a week, and the obvious things are exactly the ones nobody thinks to say out loud.

Decide what you would cut

Every project gets cut somewhere. Budgets tighten, deadlines arrive, a feature turns out to be three times harder than it looked. Cutting is not a failure of the project. It is a normal part of every build that has ever shipped.

Cutting will happen. The only question is who decides what gets cut.

If you have not split your must haves from your nice to haves, that decision gets made for you, by a developer under deadline pressure, without you anywhere near it. They will guess. Sometimes they will guess wrong, and you will find out at the worst possible moment.

So be ruthless before the project starts. A must have is something you would delay launch over. If you would not push the date for it, it is a nice to have, no matter how attached to it you feel. Most projects stand on three or four true must haves. The rest is upside.

Say the constraints out loud

Budget. Owners hide the number because they fear being charged exactly that much. What hiding it actually buys you is a proposal priced for a project that does not exist, a round of awkward renegotiation, and lost weeks. A range works fine. A good developer designs to your range and tells you what fits inside it.

Deadline. Give the real date and the reason behind it. Live before the spring trade show is a constraint a developer can plan backwards from. As soon as possible is not a date, and it tends to produce work that is neither soon nor finished.

What already exists. Your logo, your photos, the spreadsheet of customers, the card reader you are not willing to give up, the domain your nephew registered in 2019. Listing what exists saves your developer from rebuilding it and saves you from paying for it twice.

Success. Say what you will check, in terms you can actually verify. The physiotherapist knows hers: rebooking happens in the room, not through three days of phone tag. If you cannot describe how you will know it worked, the project cannot fail, and a project that cannot fail cannot really succeed either.

A brief you can copy

Here is the whole thing as one paragraph. Fill it in and send it as written. I run [your business] and this is being built for [one specific person]. When it is done, [the one sentence of what becomes true]. I would delay launch over [your must haves], and I would happily cut [your nice to haves]. Here are examples I like, [links, each with one line on why], and one that feels wrong to me, [link, plus why]. I already have [logo, photos, tools, content, accounts]. My budget is between [low] and [high], I need it live by [date] because [the real reason], and I will know it worked when [something you can check yourself].

That paragraph takes an hour to write well, and it is the most valuable hour of the whole project. Every line in it closes a gap your developer would otherwise fill with a guess.

One last thing. When you send a brief like this, a good developer comes back with questions. That is not hesitation. That is the brief working, because every question asked now is a rebuild you are not paying for later. If you want a second pair of eyes on yours before it goes out, send the draft to us at oddesys.com and we will tell you what we would ask.