How to Brief a Developer So Your Project Actually Ships

I have rescued enough stalled projects to notice a pattern. The code was rarely the real problem. The project started without a clear answer to "what does done look like?", and every week added a little more scope, a little more confusion and a little less budget.

The good news is that a better start is cheap. It takes a one-page brief and an honest conversation.

The one-page brief

You don't need a 40-page specification. You need these seven things, in plain English.

1. The problem. What is going wrong or costing money today? "We lose enquiries because nobody follows up within a day."
2. Who uses it. Staff, clients, the public? Roughly how many of each?
3. The must-haves. The five to ten things the first version has to do. Be ruthless.
4. The nice-to-haves. Everything else, in a separate list, so it doesn't creep into version one.
5. What exists already. Current tools, spreadsheets, website, data you need to keep.
6. Budget range and deadline. A range is fine. "No idea" makes every quote a guess.
7. What success looks like. A number if possible: hours saved, enquiries converted, errors reduced.

If you can't fit the first version on one page, it isn't a first version yet.

Questions a good developer will ask you

If a developer quotes without asking most of these, be wary.

• What happens today, step by step, including the workarounds?
• Who needs access to what, and who must not see certain data?
• What data do you have already, and what state is it in?
• Which other systems does this need to talk to?
• Who will make decisions and sign off work on your side?
• What happens to the system after launch: hosting, updates, support?

These questions are where most of the real risk is found, long before it costs money.

How a well-run project feels

• Short cycles. You see working software every week or two, not a big reveal after three months.
• A visible list. You always know what is done, what is next and what has been pushed to later.
• Changes are discussed, not absorbed. New ideas go on the list with their cost, and you choose.
• Launch is boring. Data is migrated by script, tested, and the switch happens on a planned date.

As a technical project lead I run projects this way because it keeps budgets honest for both sides.

Warning signs to walk away from

• A fixed price for a vague brief, with no discovery phase
• No questions about permissions, data protection or backups
• You won't own the code or have access to the hosting
• "We'll show you when it's finished"
• Nobody can explain how they deploy updates or recover from a failure

After launch

Budget for the first few months after go-live. Real users always find things nobody predicted, and quick fixes in those weeks decide whether staff adopt the system or quietly return to the spreadsheet.

Agree upfront who handles hosting, security updates, backups and small changes, and how much it costs.

Want a second pair of eyes?

If you have a brief, a quote, or a project that has stalled, I'm happy to review it and tell you where the risks are. You can see the projects I've delivered or send me your brief.