How to write a software scope a vendor can actually fix a price on

A fixed price is only as good as the scope it is based on. Vendors that quote fixed prices on vague scopes either pad the quote heavily or plan to renegotiate later. Buyers who want a real fixed price therefore have one job before asking for a quote: write a scope that states outcomes, boundaries and acceptance criteria clearly enough that two engineers who have never met would build the same thing. This guide gives a format that does that, shows how to turn common vague phrases into testable statements, and explains what a vendor should send back.

What a scope document is for

A scope document is not a design, a technical specification or a backlog. It is the agreement about what will exist when the work is done and how both sides will know. The technical design that satisfies it can be written afterwards, by whoever owns the architecture. Keeping the two separate matters: a scope that dictates implementation detail ties the vendor's hands without improving the outcome, while a scope that only describes a vision cannot be priced at all.

A useful test: if you handed the document to a competent vendor with no further conversation, could they quote a fixed price and later prove they delivered it? If the answer is no, the document is not yet a scope.

The format

A workable scope document has seven sections. Most can be short. The acceptance criteria are usually the longest part, and they are the part that earns the fixed price.

1. Context and purpose

Two or three paragraphs: what the system is, who uses it, what business problem this piece of work solves. This is background for the vendor's architect, not a requirement. It prevents the kind of technically correct delivery that misses the point.

2. Outcomes

A numbered list of things that will be true when the work is done, written from the user's or the system's point of view. Each outcome is one sentence. Examples:

• A customer can export all invoices for a selected date range as a single PDF.
• The nightly reconciliation job runs without manual intervention and reports its result to the finance channel.
• The public API rejects requests above the configured rate limit with a documented error response.

Outcomes are not features in a marketing sense and not tasks. "Build an export module" is a task; "a customer can export invoices as PDF" is an outcome.

3. Boundaries: what is explicitly out of scope

The most valuable section and the one most often omitted. Write down the adjacent things that will not be built, so that neither side assumes them. For example: no changes to the mobile application; no migration of historical data before a given date; no new user roles; the existing authentication system is used as is. Every boundary you write removes a future argument.

4. Acceptance criteria

For each outcome, the observable evidence that it has been delivered. Good acceptance criteria share three properties: they can be checked by someone other than the author, they do not depend on opinion, and they are checked on the delivered system rather than on a description of it. Three forms work well:

• Behavioural statements: "Given an account with 200 invoices in March, when the user exports March, a single PDF containing all 200 invoices is produced within the request timeout."
• Test requirements: "Automated tests cover the export for empty ranges, single invoices, ranges spanning a year boundary, and accounts with more than 10,000 invoices."
• Artefact requirements: "Documentation describes the export endpoint, its parameters, error responses and limits."

Numbers in acceptance criteria should be the buyer's real requirements, not round figures chosen to sound rigorous. If you do not know the required limit yet, say so and decide it before the quote.

5. Inputs the buyer provides

List what the vendor will receive and when: a copy of existing code as a package, sample data, API credentials, design assets, a named person who answers written questions and within what response time. Delivery dates in a fixed-price contract are conditional on these inputs, so they belong in the scope.

6. Constraints

Technology constraints (language, framework, database, hosting), compliance constraints (data residency, logging, retention), and integration constraints (existing systems that must keep working). Keep these to genuine constraints. A preference stated as a constraint reduces the vendor's options without benefit.

7. Delivery form

How the work arrives: what each delivery contains, at which milestones, how it is previewed and tested on your side, where documentation lives, and how acceptance is recorded. If you expect staged deliveries rather than a single hand-over at the end, say so. That is also the delivery form we use: a written progress report every day and, at every milestone, a password-protected preview link, a test report and the code as a package, as described on how it works.

Turning vague wording into testable wording

The difference between a scope that can be priced and one that cannot is usually in the verbs and adjectives. Some common replacements:

Note what changed. Each testable statement names a condition, an observable result and, where needed, a reference environment. None of them says how to build it.

Sizing: how much scope per fixed price

A large plan is best bought as a sequence of fixed-priced scopes rather than one enormous one. Each scope should be small enough that its acceptance criteria fit on a few pages and large enough to deliver a complete outcome. A good first scope is one that is real, bounded and representative: it touches the actual codebase, exercises the vendor's whole process, and produces something that stays in production.

This is the reasoning behind the trial build in our model. The first scope is a genuine part of the plan, fixed at 9,900 euros and delivered within 72 hours of written confirmation. Its result calibrates the fixed quote for the remainder. A separate guide covers how to prepare for the trial build.

What a good vendor sends back

A scope document is the buyer's input. The vendor's response should be a written scope description: the vendor's restatement of what will be delivered, in its own words, with any assumptions made explicit, the acceptance criteria confirmed or refined, open questions listed, and the fixed price and delivery terms attached. The buyer confirms that document in writing, and that confirmation is the moment the price and the clock start.

Warning signs in a vendor's response: a price without a restated scope; "to be defined during the project" against items that affect the price; acceptance criteria quietly replaced by "as agreed"; or a refusal to write down what is excluded. Each of these moves risk back to the buyer.

Change control after the scope is fixed

Scope will change; the point of a good scope document is that changes are visible. Agree a simple mechanism: a change is described in writing, the vendor states its effect on price and delivery, and the change is built only after written confirmation. Keep the record alongside the original scope. On a well-run project this takes a few paragraphs per change and keeps the fixed price genuinely fixed.

A short checklist before you send the scope

• Every outcome is one sentence and describes a result, not a task.
• Every outcome has at least one acceptance criterion that someone else could check.
• The out-of-scope list exists and names the adjacent things you are not buying.
• Inputs you must provide are listed with dates.
• Constraints are genuine constraints, not preferences.
• The delivery form says what arrives when and how acceptance is recorded.
• Nothing in the document depends on a meeting to be understood.

The last point is deliberate. A scope that can only be understood with a call is not finished. All our engagements are run in writing, which is also why our model works across time zones and why every decision stays on the record. The large software projects page explains the engagement; the request form accepts a scope in any state, including a rough one, and returns a written scope description.

Frequently asked questions