Capped Investment vs Fixed Price: A Guide to Software Build Caps

Does a fixed price mean a fixed scope?

One of the most common misconceptions in bespoke software development is that a fixed price means a fixed scope. In practice, the two work very differently.

A capped investment model (sometimes called a Build Cap) sets a maximum price for the build phase. This is the most the client will pay. Within that cap, scope is flexible. Features are estimated during discovery and allocated individual budgets, but as detailed requirements are elaborated during the build, some features will cost more than estimated and some will cost less. The cap stays the same; the scope adjusts to fit.

This is not a reduction in what the client receives. It is a mechanism that puts the client in control of priorities. If a high-value feature needs more effort than originally estimated, the client can choose to defer a lower-priority item and redirect that budget. The total investment does not change, but the client gets to decide what matters most.

How is the Build Cap made up?

Within the Build Cap, each functional area has an estimated budget based on discovery. A programme contingency (typically around 20%) is included to absorb the natural variance that occurs as features are built. Most features will come in close to estimate; some will come in under, and some over. The contingency covers this across the programme as a whole.

The important detail is where the contingency sits. It is included within the cap, not added on top of it. The Build Cap already accounts for the variance you would expect across a real programme of work, so the headline figure is the genuine maximum rather than an optimistic starting point that grows once delivery begins.

How does contingency get released?

Contingency is not held back as a block at the end of the project. As each feature completes, any unused budget is released. This means the client has visibility throughout the build of how much contingency remains and can make informed decisions about whether to bring additional scope into the programme.

This matters because it changes the nature of the conversation. Instead of discovering at the end of a project that there is money left over (or that it has quietly been consumed), the client sees the position throughout. Contingency becomes a live, visible figure that informs decisions rather than a hidden buffer.

What happens when a feature exceeds its estimate?

If a feature exceeds its estimate, the client can defer a lower-priority item to a post-MVP backlog. Deferred items are not lost. They can be delivered under a separate statement of work after the initial build, either as a one-off project or via an ongoing change retainer (a committed monthly resource with a prioritised backlog).

The key point is that the client makes the choice. When a high-value feature needs more effort than expected, the client decides whether to fund it by deferring something less important, rather than being presented with a bill for additional work. The cap holds, and the trade-off is explicit and visible.

Because deferred items relate to what ultimately gets delivered and accepted, they connect closely to how delivery and sign-off are handled. For how acceptance and rejection work in practice, see our guide on acceptance testing and UAT clauses.

How does underspend work?

Underspend works the same way as deferral, in reverse. As features come in under budget, the freed capacity can be applied to bring post-MVP features into scope sooner. This is managed and agreed at regular Steering Committee meetings, giving the client ongoing visibility and control.

So the flexibility runs in both directions. If the programme is tracking favourably, the client can pull valuable features forward into the initial build instead of leaving them for later. If a priority feature needs more room, a lower-priority item can move to the backlog. In every case the decision sits with the client and the cap stays fixed.

Where do these decisions get made?

Deferrals and underspend redirection are managed and agreed at regular Steering Committee meetings. This is what keeps the model transparent rather than ad hoc. The Steering Committee gives the client a recurring forum to see budget consumption and remaining contingency, weigh up priorities, and agree changes to the allocation within the cap.

This governance is the difference between flexible scope and uncontrolled scope. The cap provides the financial discipline, and the Steering Committee provides the decision-making rhythm. Together they let the client adapt as they learn without renegotiating the commercial deal each time.

How is this different from fixed-price, fixed-scope?

In a traditional fixed-price, fixed-scope contract, any change to requirements triggers a commercial negotiation. This creates friction, slows delivery, and often means the client ends up paying more than the original price or accepting a product that does not reflect what they actually need.

The capped investment model removes this friction. The budget is agreed upfront, and the client retains flexibility to adjust priorities as they learn more during the build. Crucially, scope adjustment within the cap does not trigger the change control process, so reprioritising features is a normal part of delivery rather than a contractual event.

The practical effect is a better product for the same money. In a fixed-scope contract, requirements are frozen at the point of least knowledge, before detailed design has even begun. In a capped investment model, the client keeps learning throughout the build and steers the budget towards what turns out to matter most.

What to look for in your contract

When reviewing a capped investment arrangement, look for:

• A clearly defined Build Cap that represents the maximum financial commitment.
• Feature budgets with contingency included within the cap, not on top of it.
• A mechanism for deferrals and underspend redirection, agreed at Steering Committee.
• Reporting on budget consumption and contingency usage at regular intervals.
• Confirmation that scope adjustment within the cap does not trigger the change control process.

Where to go from here

This guide is a deep dive into one area of a bespoke software agreement. For the wider picture, including IP licensing, liability caps, acceptance testing, exit rights, and support, see the practical guide to software development contracts.

A well-structured capped investment model gives you a maximum price and the freedom to steer priorities as you learn. If you are reviewing a software development contract and want to discuss how the Build Cap, contingency, and Steering Committee governance would work for your project, book a consultation.

This guide explains how common software development contract terms work in plain English. It is not legal advice. For advice specific to your circumstances, consult a solicitor qualified in technology and commercial contracts. It reflects common UK market practice as at June 2026.