How to brief a developer so you get what you pictured

The gap between what a client pictured and what got built is almost never caused by bad code. It is caused by two people using the same words to mean different things, for six weeks, without noticing.

A good brief is not a long brief. It is a brief that makes disagreement happen early, while disagreement is still cheap.

Describe the problem, not the solution

The most common brief we receive is a description of a solution. Build a landing page with a hero video, three feature cards and a testimonial slider.

That tells us what to make. It does not tell us what it is for, which means we cannot tell you when you are about to spend money on something that will not work. A hero video on a page whose visitors arrive on mobile data in a hurry is a decision worth questioning, and we can only question it if we know who is arriving and why.

Compare: people find us through Instagram, they do not know what we charge, and they leave without asking. That is a brief. It has a problem in it, and there are four different ways to solve it.

Say what you want to be true afterwards. Let the person you are paying propose how.

The five things worth writing down

Who is this for. Not demographics. Circumstances. Someone comparing three quotes on a phone at eleven at night is a different visitor from a procurement manager with a checklist.

What should they do. One primary action per page. If everything is important, the page has no hierarchy and the visitor picks nothing.

What already exists. Domain, hosting, analytics, a half finished Figma file, a previous developer's repository. Especially the awkward parts. Finding out in week three that the domain is locked with a registrar nobody has the login for is a real delay caused by an easily avoided omission.

What must not change. Brand colours signed off by someone senior. An integration finance depends on. A URL that appears on printed packaging. Constraints are a gift, because they eliminate whole branches of wasted work.

When and why. A date attached to a reason gets respected. A date with no reason attached gets negotiated at the worst possible moment.

Show, do not adjective

"Clean", "modern", "premium" and "minimal" mean roughly nothing in isolation. Everyone agrees they want all four, then discovers they had entirely different pictures in mind.

Three links to sites you like is worth more than a page of adjectives. Even better, say specifically what you like about each one. The typography, the way it feels on a phone, the density of the pricing page. That is the sentence that actually transfers a picture from your head to someone else's.

Links to sites you dislike are just as useful, and people rarely include them.

Say what you do not know

The strongest briefs contain sentences like: we are not sure whether we need accounts yet.

That is not a weakness. It is the single most valuable line in the document, because it points at the decision that should be made first, before it has quietly hardened into an assumption that thirty other things depend on.

A brief that pretends to certainty it does not have produces a quote that is wrong in ways nobody can see until it is expensive.

What a good quote looks like back

You should expect a scope that repeats your problem back in different words, so you can tell whether it was understood. A list of what is explicitly not included. A timeline with the dependencies named, including the ones that are yours, like supplying copy or approving a design.

If a quote is a single number with no scope attached, that is not a price. That is a hope, and you will find out whose hope it was somewhere around week five.

The honest version

You do not need a perfect brief. You need an honest one. A paragraph describing the actual problem, three reference links, a real constraint and a genuine deadline will get you a better result than ten pages of specification written to sound thorough.

Send us the messy version. We would rather ask five questions than build the wrong thing carefully.