Offer
Fixed-scope projects: a defined outcome, delivered
A written scope, a fixed price, and a team that owns the outcome rather than billing you for the hours it takes to find it.
Start with the workflow that costs you the most
Tell us what the process is and what it currently runs on. A senior engineer reads it and replies with either questions or a straight answer that we are not the right fit.
- Discovery
- £500–£1,500
- credited against the build if you proceed
- Build
- £8,000–£25,000
- fixed price against a written scope
- Care plan
- £200–£600
- per month, optional, cancel any time
What this is
There are three ways to buy software from outside your business, and they fail in different ways. You can hire contractors by the day, which gives you control and hands you every risk: if the estimate was wrong, you pay for the extra days. You can engage an agency on time and materials, which is the same arrangement with a larger invoice. Or you can buy a defined outcome at a fixed price, which transfers the estimating risk to the supplier and costs more on paper because of it.
This page is about the third. It suits a buyer with a clear objective, a budget that has to be approved in advance, and no appetite for managing developers day to day. It does not suit exploratory work where nobody yet knows what should be built, and we would steer you away from a fixed price in that case rather than sell you one that has to be renegotiated in month two.
The distinction that matters is not the pricing model but who is accountable. On a day-rate arrangement, the person accountable for the outcome is you. On this one it is us, and the fixed price is what that transfer of risk costs.
You will recognise some of these
- You need board or budget-holder approval before starting, and "roughly this much" will not get it
- A previous project ran considerably over on a time-and-materials contract
- You have no internal engineering manager to direct contractors day to day
- You have been quoted a day rate and cannot translate it into a total cost
- The requirement is clear enough to write down, and nobody has written it down
- You need a firm date because something external depends on it
What is included
- A written scope defining the outcome, the boundaries and the acceptance criteria
- A fixed price against that scope, and a stated delivery date
- A named senior engineer accountable for delivery, who was in the scoping conversation
- Working software you can use throughout, rather than a reveal at the end
- A change-order process with prices agreed before any extra work begins
- Handover: code, documentation, deployment and access, all in your name
What is not included
Stated as plainly as the inclusions. A fixed price only means something if the boundary around it does.
- Open-ended discovery. If the requirement cannot yet be written down, a fixed price is the wrong instrument, and we will propose a paid discovery phase that produces a scope worth fixing.
- Work whose delivery depends on a third party we cannot get a commitment from. We will not price a date we do not control.
- Ongoing feature development after handover. The project ends when the agreed outcome is delivered; anything after that is a new engagement with its own scope.
- Requirements that arrive mid-build. Those are change orders, priced and dated before work starts, which is the mechanism that keeps the original number honest.
- Staffing your team. If what you actually want is engineers you direct day to day, that is a capacity arrangement rather than a fixed-scope project, and it is a different conversation.
Tell us which workflow it is
A short description of the process and what it runs on now is enough to get a straight answer on whether this fits.
When a fixed price is the wrong choice
Fixed-price contracts fail predictably when the requirement is genuinely unknown at the start. Both sides then have an incentive problem: the supplier has to defend a scope that was guessed, and the client has to argue that each new discovery was implied by the original agreement. Nobody enjoys this and the software suffers for it.
If you are exploring, prototyping, or building something whose shape will change as you learn, a fixed price is the wrong instrument and we will say so. The honest alternatives are a paid discovery phase that produces a scope worth fixing, or a capacity-based arrangement where you buy a team and steer it.
The signal we look for is whether you can describe what "done" means without using the word "and then we will see". If you can, a fixed price protects you. If you cannot, it protects nobody.
Against hiring contractors directly
Hiring contractors by the day is often cheaper per hour, and for a team with strong internal engineering management it is frequently the right answer. What it requires is somebody on your side who can specify the work, review the output critically, and notice early when it is going wrong. That person is the hidden cost, and businesses without one usually discover it about two months in.
The failure mode is not bad contractors. It is unmanaged ones: competent people building something reasonable that turns out not to be what was needed, because nobody was close enough to the work to catch the divergence. The daily rate looked like the whole cost and the management was assumed to be free.
A fixed-scope project moves that responsibility to the supplier. You pay more per hour of engineering and you buy the specification, the accountability and the estimating risk with it. Which is better depends entirely on whether you have that person, and we would rather ask you than assume.
Common questions
What if the scope turns out to be wrong?
There are two cases and they are treated differently. If we misjudged the effort on something that was in the agreed scope, that is our cost and the price does not change: that is exactly the risk you paid a fixed price to transfer. If you want something that was not in the scope, it is a change order with its own price and its own effect on the date, agreed before it is built. Keeping those two apart in writing is what stops the argument later.
Is a fixed price more expensive?
Usually yes on paper, and that is not a markup so much as the price of certainty. The supplier is absorbing the risk that the work takes longer than estimated, and that risk has to be costed. What you get for it is a number you can take to a budget holder and a supplier whose interests are aligned with finishing rather than with continuing.
How do you handle scope creep?
By writing it down rather than absorbing it. Anything outside the agreed scope becomes a change order with a price and a date impact, agreed before work starts. Absorbing changes quietly sounds generous and is not: the time comes out of the rest of the build, and the parts that suffer are the ones nobody is watching that week.
Can we start fixed-price and move to ongoing work?
Yes, and it is a common shape. The fixed-scope project delivers the defined outcome, and afterwards you either take the care plan for hosting and small changes, or move to a capacity arrangement for continued development. Starting fixed is a sensible way for both sides to find out whether they want the longer relationship.
Who is actually doing the work?
Senior engineers, and the person who scoped the project is accountable for delivering it. You are not sold an experienced lead in the pitch and handed a different team afterwards. If we do not have the capacity to staff it properly at the time you need it, we will tell you that instead of taking the work and stretching.
Related
The capability pages behind this work, and the other offers in this set.
Which spreadsheet would you kill first?
Describe the workflow and what it runs on today. If it is not a fit for a fixed-scope build, we will tell you that rather than sell you one.
- 01A senior engineer reads it. Not a form queue, and not an account manager.
- 02We reply either with questions or with a straight answer that we are not the right fit.
- 03If it looks like a fit, a technical call with the person who would actually run the delivery.
- 04Then scope, effort and risk in writing, before anyone signs anything.