A fixed price is a promise about a specific set of work. If the set of work is vague, the price is a guess dressed up as a promise, and one side will lose when the guess turns out wrong. The scope document is what turns the price into something real.
Here is what we put in one, and why each part earns its place. Use this as a checklist when you read a proposal from anyone, including us.
1. The problem, in a paragraph
Start with what is wrong today and what the system should change, in plain language. Who is affected, what do they do now, and what should be different afterwards?
This paragraph is the tiebreaker when two readers interpret a requirement differently. "Reduce the time spent building quotes" is a better anchor than "build a quote module", because it lets both sides ask whether a given feature helps.
2. Who uses it, and what each role can do
List the user types: customer, agent, administrator, finance. For each, say what they can see and do. Permissions are one of the most common sources of late surprises, because "the admin can manage bookings" means different things to different people.
If there are roles you haven’t thought about yet, say so. An open question written down is far better than an assumption.
3. The features, each with acceptance criteria
Each feature gets a short description and a test anyone could run. Not "the system supports deposits", but:
- A customer can pay a deposit of a percentage set per product.
- The balance due date is calculated from the travel date.
- If the balance isn’t paid by the due date, the booking is flagged for staff, and no automatic cancellation happens.
Acceptance criteria are how you decide, at the end, that a feature is finished. They also expose gaps early: if you can’t write the test, you don’t yet know what you want.
4. What is explicitly not included
This is the most valuable section and the one most often missing. List the things a reasonable person might assume are included and aren’t.
Typical entries: native mobile apps, data migration beyond a stated set of tables, translation into other languages, SEO work, content writing, ongoing hosting, training sessions beyond one, reporting beyond the listed reports, and integrations that aren’t named.
A long exclusions list doesn’t signal reluctance. It signals that both sides have thought about the edges. Disputes mostly arise in the gap between "I assumed" and "I didn’t".
5. Integrations and data
Name every external system the project touches: payment providers, supplier APIs, accounting software, email services. For each, state who provides the credentials, whether a sandbox exists, whether the documentation is real, and who is responsible for fees.
Where an integration is poorly documented, the scope should say that the first phase is investigation and the build is quoted after. We cover this in integrating a supplier API with weak documentation. A fixed price against an API nobody has examined is a gamble for the developer, and the buyer pays for the gamble in padding or in a mid-project argument.
Also cover data: where existing data comes from, in what format, who cleans it, and what happens to records that fail to import.
6. What you provide, and by when
A project depends on the client’s input as much as the developer’s work. Write down what is needed: content, logos, product data, test accounts, decisions on named questions, feedback on each milestone within a set number of working days.
Say what happens when input is late. The usual answer is that the timeline moves by the same amount, and extended delays may mean the work is rescheduled around other commitments.
7. Milestones and payments
Break the work into stages that each produce something you can open and test. Tie payments to those stages, with amounts and trigger events stated. "On acceptance of milestone two" is clearer than "halfway through".
State how long you have to test each stage and what counts as acceptance. If the answer is silence, say how many days of silence count as accepted. Without that, a stage can stay open indefinitely.
8. How changes are handled
Changes will come, and that’s healthy, because you learn as you see the real thing. The scope should say how they are dealt with: a change is described in writing, the developer states the effect on price and timeline, and the work starts only after you agree.
This protects both sides. You’re never billed for work you didn’t approve, and the developer isn’t asked to absorb scope growth for free.
9. Technical decisions that affect ownership
Name the main technology choices and their reasons. State where the code is hosted and that the repository will be in an account you control. List third-party components with their licences and any recurring fees: hosting, domain, email sending, map or payment fees, AI usage costs.
For AI features, add running costs. A system that calls a language model has a cost per use, and the person paying for it should see an estimate.
10. Definition of done and handover
Say what the end looks like. Acceptance tests pass, the system is deployed, and the handover items are delivered: repository, README, architecture note, data model, deployment steps, credentials and a recorded walkthrough. Our list is in what a proper software handover contains.
Also state what happens after delivery: a defined period for fixing defects against the agreed criteria, how bug reports are made and how support continues, if at all.
11. Risks and assumptions
List what you’re assuming and what could go wrong. "Assumes the supplier provides sandbox credentials by week two." "Assumes fewer than a stated number of products need importing." If an assumption fails, the price or timeline may change, and writing that down in advance makes the later conversation shorter.
12. Signatures and terms
Finally, who signs, which law applies, how confidentiality is handled and how either side can end the agreement. A scope document isn’t legal advice or a substitute for a proper agreement, and a lawyer should review the commercial terms.
When a fixed price is the wrong choice
Fixed price suits work that can be described in advance. It suits research badly, or a project where the requirement will be discovered by building. In those cases a Discovery Sprint first, or a time-boxed engagement with a clear review point, is more honest than pretending the scope is known.
Our Discovery Sprint exists to produce exactly this document: a written specification, risks and a fixed-price quote, which you keep whether or not you build with us.