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

Start with outcomes, not features

There is a natural way to write a brief: describe what the system should have — a dashboard, a login screen, a reporting page. It reads like a clear specification, and it leaves out what problem those things are solving and 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.

One sentence at the top changes what you get back. Describe 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, and you already know yours better than any developer will after three meetings. 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, and it is the part only you can supply. 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?

That one document does three things for you: it lays your own process out in one piece, which is the version you will be working from for the rest of the project; 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 — a system pushing data out when something happens, rather than answering when you ask); and it gives a developer what they need to estimate accurately rather than guess.

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

You do not need to be technical to read a quote well. A quote that arrives as a single number with no breakdown tells you 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 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 — and judging questions needs no technical knowledge at all. 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 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 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.