How to Brief a Developer: A Non-Technical Owner's Guide to Getting a Straight Scope

Start with outcomes, not features

The most common briefing mistake is describing what the system should have — a dashboard, a login screen, a reporting page — without explaining what problem those things are solving or who is using them. A developer who receives a list of features will build exactly those features. What they will not do is tell you that two of them do not solve the actual problem.

Start your brief with a single sentence that describes the outcome, not the system: 'We need to stop our team from manually re-entering customer information that our booking system already holds' is more useful than 'We need a dashboard.' The outcome sentence gives the developer context to ask the right questions and propose the simplest solution — which is often not the most obvious one.

Describe your users, not your wishlist

Every piece of software is used by specific people in a specific context. A field technician using an app on a site with poor connectivity has completely different requirements than an office manager using the same system on a desktop at a desk. Those differences determine which technical choices are correct and which are expensive mistakes.

For each type of user in your system, write: who they are, what they are trying to accomplish, what device they use, and what happens when the system fails them. This is not a design exercise — it is scope control. Unclear user context is one of the primary causes of scope growth during a build.

Document the current process, not the ideal system

Before you describe what you want the system to do, write down what your team currently does. Step by step. Where does the information come from? Who touches it and in what order? Where does it end up? Where does it get entered twice? Where does it fall on the floor?

This documentation does three things: it forces you to understand your own process before asking someone else to build software for it; it surfaces the constraints a developer needs to work around (the accounting system that only exports CSV, the supplier's API that only sends webhooks); and it gives a developer the information they need to estimate accurately rather than guess.

How to read a quote — and what vague ones are hiding

A quote that arrives as a single number with no breakdown is a warning sign. It tells you that the developer has not broken the work into components — which either means they have not thought it through carefully, or they are reserving the right to redefine scope when the work starts. A quote that arrives as a line-item breakdown — feature A: X hours, integration B: Y hours, deployment and testing: Z hours — is a quote you can have a real conversation about.

• Ask for a breakdown by feature or phase. If the developer cannot provide one, ask why.
• Check what is explicitly excluded. A quote that does not mention testing, documentation, deployment, or post-launch support probably assumes you will handle those separately — or assumes you will not notice they are missing.
• Look for the word 'approximately.' Approximate quotes become actual invoices. Ask what assumptions the approximation depends on.
• Ask: what would cause this to go over budget? A good developer has a specific answer. A vague answer ('if requirements change') is not reassuring.
• Ask for a fixed-price quote or a capped time-and-materials arrangement. A purely open-ended time-and-materials engagement transfers all budget risk to you.

The questions that separate good developers from expensive ones

The quality of a developer's questions tells you more than their portfolio. A developer who asks 'how many users will this need to support in year three?' and 'what happens to the data if someone makes a mistake?' is thinking about the real system. A developer who immediately starts talking about the technology stack without first understanding the workflow is probably more comfortable with the technology than with your business.

1. 1Ask: 'What would you need to understand better before you could be confident in this quote?' A developer who has no questions has probably not thought about it carefully enough.
2. 2Ask: 'What is the most common way a project like this goes over budget?' Good answer: a specific scenario (unclear requirements around X, scope growth in Y). Bad answer: 'when clients change their minds.'
3. 3Ask: 'Is there a simpler way to solve this that I haven't considered?' A developer who suggests a less expensive approach has earned more trust than one who builds exactly what you asked for.
4. 4Ask: 'What would you not recommend about this approach?' If the developer has no concerns, they have not thought about failure modes.
5. 5Ask: 'Who will be doing the actual work?' You need to know whether you are dealing with a solo developer, a team lead, or a sales person who will hand the project to someone you have never spoken to.

Red flags that signal a difficult engagement ahead

• The developer will not provide a written scope document — verbal agreements on scope become disputes at invoice time.
• The quote arrives within hours of the first conversation, without follow-up questions.
• The developer insists on owning the code repository or hosting accounts.
• There is pressure to sign or pay a deposit before a scope document exists.
• References are not available or the developer deflects when you ask for them.
• The developer's response time during the sales process is slower than you would tolerate during the project.