On this page
In short
- A fixed price moves estimating risk to the builder, but only for the work that's written down. The scope is the contract.
- A good scope says what's out as clearly as what's in, names every system the work touches, and defines what "done" means.
- Changes are normal. What matters is that each one is priced and agreed in writing before the work happens.
- Handover, documentation and ownership belong in the scope, not in a vague promise at the end.
Why fixed price, and when it isn't the right fit
On an hourly engagement, the buyer carries the risk of the estimate being wrong. On a fixed-price one, the builder does. For a company whose business isn't software, that usually matters more than anything else: the number in the budget request is the number on the invoice, and finance can plan around it.
Fixed price works best when the outcome can be described before work starts, even if some details are still open. It fits less well when the work is open-ended by nature, such as ongoing support or research where the question itself is unclear. Those are better quoted as a separate, clearly bounded piece of work, or scoped in two steps: a first fixed-price phase, then a fixed price for what follows.
The four stages
We run engagements through the same four stages. Other firms name them differently, but you should be able to recognize each of these in any fixed-price proposal you're given.
Nothing is built until you accept the written scope and price.
- Scoping call. The business problem first, then the technical one: what the system must do, who uses it, what it connects to, and what IT and security will need.
- Written scope & fixed price. After one to two weeks of working sessions with your key people: what's in, what's out, the systems involved and what counts as done, with one price for that scope. You review it with your team and procurement before accepting.
- Build. Work happens in your repositories and cloud accounts, and you review working software as it takes shape.
- Launch & support. Releases go out through automated pipelines with infrastructure defined as code, so they can be repeated, and documentation, training and knowledge transfer let your team run and change the system. Or we can host, support and maintain it as you need.
What a good scope document contains
The scope is what the price is attached to, so it deserves more attention than the price. When you review one, look for each of these:
Sections of a fixed-price scope and what to look for in each
Goals
- What to look for
- The business outcome in plain language, so later decisions can be checked against it
Users and roles
- What to look for
- Who uses the system and what each role can see and do
Features in scope
- What to look for
- Specific capabilities, described as behavior rather than technology
Out of scope
- What to look for
- What's deliberately excluded, so nobody assumes it's included
Integrations
- What to look for
- Every system it reads from or writes to, which direction, and who owns each one
Environments and hosting
- What to look for
- Where it runs, whose accounts, and how many environments (dev, test, production)
Security and access
- What to look for
- Sign-in method, permissions, data handling, and any review it must pass
Acceptance criteria
- What to look for
- How you'll both know each part is done
Assumptions and dependencies
- What to look for
- What the price relies on, such as access, test data or a decision by a certain point
Handover
- What to look for
- Documentation, training and access you'll receive, and who owns the code
| Section | What to look for |
|---|---|
| Goals | The business outcome in plain language, so later decisions can be checked against it |
| Users and roles | Who uses the system and what each role can see and do |
| Features in scope | Specific capabilities, described as behavior rather than technology |
| Out of scope | What's deliberately excluded, so nobody assumes it's included |
| Integrations | Every system it reads from or writes to, which direction, and who owns each one |
| Environments and hosting | Where it runs, whose accounts, and how many environments (dev, test, production) |
| Security and access | Sign-in method, permissions, data handling, and any review it must pass |
| Acceptance criteria | How you'll both know each part is done |
| Assumptions and dependencies | What the price relies on, such as access, test data or a decision by a certain point |
| Handover | Documentation, training and access you'll receive, and who owns the code |
How changes work
Requirements change once people see working software, and they should. A fixed-price project doesn't pretend otherwise; it makes the cost of each change visible before anyone commits to it.
- You or the builder raise a change: something new, something different, or something that turned out harder than the scope assumed.
- The builder writes down what changes and prices it, or explains why it fits inside the existing scope.
- You approve it in writing, decline it, or swap it for something of similar size that's no longer needed.
- Only then does the work happen, and the scope document is updated to match.
The warning sign is a builder who absorbs every change silently early on. It feels generous, but it usually means corners get cut later, or the goodwill runs out at an awkward moment.
What you'll need to provide
A fixed price assumes the builder can get what they need when they need it. Buyer-side delays tend to come from a few predictable places, so line them up early:
- A single decision-maker who can answer questions and accept the scope and each delivery. If nobody on your side has written requirements before, our project brief walks through what to write down.
- Time from the people who do the work today; they know the exceptions nobody wrote down.
- Access to the systems being integrated, including test or sandbox environments where they exist.
- Realistic sample data, anonymized if needed, for building and testing.
- Your IT and security requirements up front, so they shape the design rather than arriving at the end.
Ready to scope something?
The scoping call is stage one. Bring the problem and a list of the systems involved; you'll leave with a clear approach and the real risks, and what a fixed-price quote would cover, whether or not you go ahead.
How to prepare for a scoping call
Bring these, even in rough form
- A short description of the problem and who feels it most.
- How the process works today, including the spreadsheets and workarounds.
- The systems involved: databases, line-of-business apps, historians, identity provider, cloud accounts.
- Who will use the new system, roughly how many people, and on what devices.
- Constraints you already know about: security policies, hosting rules, compliance requirements.
- Who else needs to approve the project, and what they'll want to see.
- Any hard dates the business is working toward.
Red flags in a fixed-price quote
- A price with no written scope, or a scope that's a paragraph long.
- No acceptance criteria. If "done" isn't defined, the price isn't really fixed.
- Integrations described vaguely, such as "connect to your ERP" without naming the system, the data or the direction.
- Hosting in the builder's accounts with no plan to move it to yours.
- No mention of code ownership, documentation or handover.
- An assumptions list that quietly moves the risk back to you, for example assuming requirements won't change or that every integration has a documented API.
Our How we work page sets out how we handle each of these, including ownership, NDAs and security reviews. For a broader list to put to any firm, see questions to ask before hiring a software development firm, and for what the last stage should deliver, what a proper software handover should include. If you're still deciding whether to build at all, start with custom web apps vs. low-code.
See it applied
- Illustrative sample. Not client work.See a sample scope for an internal tool →An invented request and approval portal that replaces a spreadsheet and email, on an existing SQL Server database with the company's existing single sign-on.
- Illustrative sample. Not client work.See a sample handover package →The handover index for an invented plant-floor dashboard: repositories, infrastructure as code, the pipeline, runbooks, a data dictionary, the credential handover list, alerts, known limitations and sign-off.
Share this guide
Related services
Topics