Questions to ask a dev agency
Most of these are uncomfortable to ask and cheap to answer honestly. That asymmetry is exactly what makes them useful.
How to write a spec an agency can actually quote from
A vague brief costs you money twice. First in the quote, because every ambiguity is a risk the studio prices defensively — and defensive pricing is always in their favour, not yours. Then during the build, when the ambiguity gets resolved as a change request.
You do not need a technical specification and you should not attempt one. You need to remove the guesses. Eight sections do that, and a founder who knows their business can write them in a morning.
1. The one sentence
What the product does, for whom. "A booking tool for independent physiotherapists to manage appointments and take deposits." If you cannot write this sentence, nothing downstream will be accurate, and that is worth discovering before you pay anyone.
2. Who uses it, and what each of them can do
List every type of user and what they are allowed to do. This is the single highest-value section, because roles and permissions drive more of the cost than almost anything else and are frequently discovered halfway through.
| User type | What they can do | What they must not see |
|---|---|---|
| Patient | Book, reschedule, pay a deposit | Other patients, clinic finances |
| Practitioner | Manage their own diary and clients | Other practitioners' clients |
| Clinic owner | Everything, plus reporting | — |
Three roles is a different product from two, and five is a different product again. Write them down.
3. The core journeys, start to finish
Three to five numbered walkthroughs of the things the product exists for. Plain sentences: "Patient opens the booking link, picks a practitioner, sees available slots, chooses one, enters details, pays a deposit, receives confirmation by email."
Write what happens when it goes wrong too — the slot was taken while they were typing, the card is declined. Unhappy paths are where the real engineering time goes, and a brief that only describes success is a brief that will be repriced.
4. What it must connect to
Every external system, named. Payment provider, calendar, accounting tool, CRM, identity provider, anything internal. For each one, whether you already have an account and whether anyone has confirmed the API supports what you need.
5. What is explicitly not in version one
The section people skip and the one that protects you. Writing down what is out prevents a studio pricing for it defensively and prevents an argument about it in week three. It also forces the cutting exercise while it is still cheap — what belongs in an MVP covers how to decide.
6. The constraints that are not negotiable
- A date, and what depends on it. "Live before the conference on the 14th" tells a studio how to sequence. "As soon as possible" tells them nothing.
- Regulation. Health, financial or children's data changes the build substantially. Say so at the start.
- Where data may be stored. If your customers are in the UK or EEA, or you sell to enterprises, this is a real constraint.
- Anything you already own — a design, a brand, a half-built codebase, a hosting arrangement you must stay on.
7. What "done" means
How will you decide this is finished and working? Ideally a short list you could walk through yourself: a patient can book and pay, the practitioner sees it in their diary, both receive an email.
Agreeing this before the build removes the most common source of late friction, where "finished" turns out to mean different things to each side.
8. What you already know about your users
Anything real: how they do this today, what they hate about it, what they have told you. This is not padding — it is what lets a studio tell you which part of your plan is wrong, which is most of the value of hiring people who have built this kind of thing before.
What not to put in
- A technology choice, unless it is a genuine constraint. Specifying the stack without a reason removes a decision the people you are paying are better placed to make.
- Database schemas or wireframes of every screen, unless you have a designer. Describe the outcome, not the implementation.
- Padding. A four-page brief that answers the eight sections is worth more than forty pages that do not.
Why this matters more than it used to
A written spec is now the input to the build itself, not just to the quote. Where delivery is partly run by agents, the quality of the specification propagates directly into tickets, implementations and tests — the agentic SDLC describes that pipeline. A vague brief used to produce a vague estimate; it now produces vague software, faster.
What we do
Send whatever you have — bullet points are fine — and discovery on an MVP build turns it into the eight sections above, which you own whether or not you build with us. Plenty of people take that document elsewhere, and that is a reasonable thing to do with it.
The questions to ask before you sign covers the other half of the same conversation.
Frequently asked questions
What should be in a spec for a software development agency?
Eight sections: one sentence saying what the product does and for whom; every user type and what each can do; three to five core journeys written start to finish including what happens when they fail; every external system it must connect to; what is explicitly not in version one; non-negotiable constraints such as dates and regulation; what "done" means as a checklist; and what you already know about your users.
Do I need a technical specification to get a quote?
No, and you should not attempt one. Agencies need the guesses removed, not the implementation described. Leave out technology choices unless they are a genuine constraint, and leave out schemas and wireframes unless you have a designer. A four-page brief that answers the eight sections is worth more than forty pages that do not.
Why do agencies quote high for vague briefs?
Because every ambiguity is a risk they have to price, and defensive pricing runs in their favour rather than yours. The same vagueness then costs you a second time during the build, when the ambiguity gets resolved as a change request. Removing guesses before you ask for a quote is the cheapest work you can do on your own project.
What is the most important section of a project brief?
The list of user types and what each is allowed to do. Roles and permissions drive more of a build's cost than almost anything else and are commonly discovered halfway through — three roles is a materially different product from two. The second most important is what is explicitly excluded from version one.
Keep reading
What belongs in an MVP
Cutting scope is the highest-return activity in an early build, and almost nobody does enough of it. Here is a test that settles most arguments.
The Agentic SDLC, Explained
One person writes the spec and approves the release. Between those two moments, a chain of agents plans, builds, reviews, tests and ships. Here is the wiring.