How to brief a developer so you don't waste weeks or money

Here's something I wish every founder knew before hiring a developer: most projects that go wrong were already going wrong before anyone wrote code. The cause is rarely bad programming. It's a brief that said "build me an app like Uber but for X" and left the rest to guesswork.

You don't need technical language to write a good brief. You need to be clear about the problem, the people, and what "done" looks like.

Why briefs fail

• They start with the solution. "I need an app" skips the question of whether an app is the right answer. Describe the problem, and let the developer propose the fix.
• They have no success measure. If you can't say how you'll know it worked, neither of you can tell when it's finished.
• Everything is a priority. When every feature is "must have", the schedule and the budget have no room to move.
• They hide the constraints. Budget, deadline and the tools you already use change the best answer. Surprises later are expensive.

The one-page brief

A good brief fits on a page. These are the parts that matter:

1. The problem. What's going wrong today, in one or two sentences?
2. Who uses it. You, your team, your customers? How many, and how technical are they?
3. What success looks like. A number if possible: "cut lead reply time from a day to five minutes".
4. Must-have, nice-to-have, not now. Three short lists. The "not now" list is the most useful one.
5. What you already use. Tools, spreadsheets, accounts, data. Any of these might connect to what's being built.
6. Budget and deadline. An honest range. A developer can't design the right size of solution without it.

Build yours here

Fill in what you know. Leave anything you're unsure about blank. The completeness meter shows what's still missing, and a gap in your brief is a good question to ask your developer. When you're ready, copy the result and send it.

PROJECT BRIEF: (untitled)

THE PROBLEM TODAY
(to discuss)

WHO WILL USE IT
(to discuss)

WHAT SUCCESS LOOKS LIKE
(to discuss)

MUST-HAVE
(to discuss)

NICE-TO-HAVE
(to discuss)

NOT NOW
(to discuss)

TOOLS AND DATA YOU ALREADY USE
(to discuss)

BUDGET RANGE
(to discuss)

DEADLINE
(to discuss)

Questions a good developer will ask you

A brief is half the conversation. Here's how to tell you're talking to someone good: they ask questions before they quote a price.

• "What happens today when this goes wrong?"
• "Who will use this daily, and what will they hate about it?"
• "What's the smallest version that would already be useful?"
• "What do you already have that we could reuse?"
• "What would make you call this a failure in three months?"

Red flags on the developer's side

• A fixed price and date within minutes of your first message, with no questions asked.
• No mention of what happens after launch: hosting, fixes, who owns the code.
• Never saying "no" or "that's not worth building".
• Vague timelines like "a few weeks" with no milestones you can check.
• Reluctance to show you work in progress before the end.

Work in small steps

Whatever you agree, ask for short delivery cycles. Something you can click on every week or two beats a big reveal at the end. It's the cheapest insurance in software: if you're heading the wrong way, you find out after a week, not after three months.

If you have a brief, or just a rough idea you'd like to turn into one, send it to me. Even if we don't end up working together, I'll tell you what I'd tighten.