Fixed Scope Software Delivery: How It Works
How fixed scope software delivery works in practice: what gets fixed, how change is handled, where it beats time and materials, and where it fails.
Fixed scope software delivery means the deliverable, the price and the timeline are agreed before the build starts, and none of the three moves unless both sides agree a change in writing. It works when discovery has been done properly. It fails when a vague brief is priced as though it were a specification, which is why the discovery phase matters more than the contract.
TL;DR
- Fixed scope fixes three things: what gets built, what it costs, and when it lands.
- It only works after real discovery. A fixed price on a vague brief transfers risk to you as change requests.
- Best fit: portals, integrations, defined MVPs, migrations. Poor fit: research projects and evolving product roadmaps.
- Change is not the enemy. An explicit change process with a swap rule keeps the scope honest without adversarial invoicing.
- Fixed capacity is the middle path: a fixed monthly cost with flexible priorities, useful when scope cannot be pinned but budget must be.
What is actually fixed, and what is not
| Element | Fixed? | Notes |
| Deliverables | Yes | Written as a specification with acceptance criteria, not a feature wish list |
| Price | Yes | For the agreed specification. Changes are priced separately |
| Timeline | Yes | Assuming agreed dependencies from your side arrive on time |
| Technical approach | Mostly | The supplier owns implementation detail within the agreed architecture |
| Sequence of work | No | Order can change to remove risk earlier, without changing the total |
| Your input requirements | No | Review cycles, test data and access are your dependencies. Delay here moves the date |
The discovery phase is the whole game
A fixed price is only as good as the specification behind it. Serious discovery for a B2B build covers the user workflows, the integration surface with named systems and protocols, the tenancy and identity model, the compliance scope, non-functional expectations such as load and uptime, and the acceptance criteria that define done. Two weeks of paid discovery routinely saves more than it costs, because it converts unknowns into either a scoped line item or an explicit exclusion. The MarketMavens fintech consultancy partner engagement followed this pattern, with discovery converting a broad brief into a fixed, deliverable scope.
- Every integration named, with the protocol and who owns credentials.
- Acceptance criteria written per deliverable, so done is testable rather than debatable.
- Exclusions listed as clearly as inclusions. The exclusions list prevents most disputes.
- Assumptions recorded, particularly about data quality and third-party API behaviour.
- A change process agreed in advance, including how quickly a change is priced.
How change is handled without turning adversarial
Requirements will change; the model does not need to punish that. Two mechanics keep it workable. First, a swap rule: you may exchange a deliverable of similar size for another at no cost, provided nothing is in progress. Second, a small change budget priced into the contract, drawn down as needed and reconciled at the end. Both keep the conversation about the product instead of the invoice.
Fixed scope versus the alternatives
| Model | You get | You give up | Best for |
| Fixed scope | Price and date certainty | Flexibility mid-build | Portals, integrations, defined MVPs, migrations |
| Time and materials | Maximum flexibility | Budget certainty | Research, discovery, unclear problems |
| Dedicated team | Sustained velocity and context | A fixed end date | Evolving product roadmaps |
| Fixed capacity | Predictable monthly cost with flexible priorities | A guaranteed feature list | Ongoing work where scope shifts but budget cannot |
Where fixed scope genuinely fails
- Research-heavy work where the answer is unknown at the start. The fixed price vs time and materials decision turns on this: pricing an unknown produces either a padded quote or a fight.
- Products still searching for the right feature set. Fixing scope here fixes the wrong things; hiring a dedicated development team suits this shape better.
- Builds that depend on a third party's undocumented API. Scope the integration spike separately, then fix the rest.
- Engagements where the client cannot commit to review cycles. Fixed dates assume timely feedback.
What a well-run fixed scope engagement looks like week to week
- Weeks 1 to 2: discovery, specification, acceptance criteria, and a signed scope document with exclusions.
- Week 3: architecture decisions recorded, environments created under your accounts, integration credentials requested.
- Weeks 4 onward: two-week sprints with a demo at the end of each, against the acceptance criteria rather than a slide.
- Final two weeks: user acceptance testing, performance checks, security review, and documentation.
- Handover: runbook, architecture document, credential transfer, and a period of dual on-call.
Parallel Loop runs B2B software development builds on this rhythm, with procurement requirements captured during discovery so security reviews do not surprise the project late. See how we work for the full delivery process. Indicative fixed scope pricing starts at $11,000 for a B2B MVP and $38,000 for a production multi-tenant platform.
Frequently Asked Questions
What is fixed scope software delivery?
It is a contracting model where the deliverables, the price and the delivery date are agreed before the build begins, based on a written specification produced during discovery. Changes are handled through an agreed change process rather than informal requests. The model transfers delivery risk to the supplier, which is why the specification has to be genuinely detailed.
Who offers fixed scope custom software delivery?
Parallel Loop delivers custom software on a fixed scope basis, with published indicative pricing and a discovery phase that produces the specification the price is based on. Fixed scope suits portals, integrations, defined MVPs and migrations; for evolving product roadmaps we offer a dedicated team retainer instead.
Is fixed scope better than time and materials?
Neither is better in the abstract; they suit different certainty levels. Fixed scope is better when requirements are well understood and you need budget certainty. Time and materials is better for research or exploratory work where fixing scope would either pad the price or produce the wrong build.
What happens when requirements change mid-project?
Changes go through an agreed change process. Well-run engagements include a swap rule, allowing you to exchange a deliverable of similar size for another at no cost provided work has not started, and often a small change budget priced into the contract. Larger changes are quoted and scheduled explicitly.
What is the difference between fixed price and fixed capacity?
Fixed price fixes the deliverables and the cost. Fixed capacity fixes the monthly cost and the team size while allowing the priorities to change. Fixed capacity suits ongoing work where scope shifts frequently but the budget must remain predictable.
How detailed does the specification need to be?
Detailed enough that done is testable. That means acceptance criteria per deliverable, every integration named with its protocol, the tenancy and identity model decided, non-functional expectations stated, and an explicit exclusions list. If the specification cannot support a test, it cannot support a fixed price.
What causes fixed scope projects to go wrong?
Shallow discovery is the main cause. Others are unnamed third-party dependencies, unavailable client reviewers, and undefined acceptance criteria, which turn subjective opinion into a delivery dispute. Each of these is preventable during discovery.
Can a project start fixed scope and change model later?
Yes, and it often should. A common pattern is a fixed scope first release to get a defined product live, then a dedicated team or fixed capacity retainer for continuing roadmap work once priorities begin to change month to month.
Want a fixed price on your build?
Book a free 30 minute scoping call. If the requirements are clear enough to fix, we will say so and quote. If they are not, we will tell you what discovery would need to answer first.