Fixed-Scope Project
A written scope, a fixed price and acceptance criteria, delivered against a milestone plan you can check.
A Fixed Price Needs a Written Scope
A fixed price is only useful when the scope is written down. When requirements are vague, the estimate hides the gaps and the change orders arrive later.
A fixed-scope project fixes the scope, the acceptance criteria and the price before the build starts. You know what you are buying and what you will test.
What You Get
You end with working software, the tests that prove it and a runbook your team can use. The documents stay yours.
A Signed Scope and Acceptance Criteria
Every feature, interface and exclusion in writing, with the test that proves each one.
An Interface Contract for Every Connection
API payloads, data maps and error handling for each ERP, payment or third-party system.
A Milestone Plan With a Fixed Price
Each milestone names the demonstration, the acceptance test and the date it is due.
Test Evidence and a Runbook
Automated test results, a release runbook and an operational handover pack.
How the Project Runs
The work runs in five stages. You approve the scope before the price, and each milestone before the next one starts.
Scope Gate
We read your specification, list the gaps and confirm the interfaces. You decide whether to close the gaps first or move to Discovery and Design. End: a written scope with every open question named.
Fixed Proposal
We price the scope, name the team and set the milestone dates. You decide whether to sign. End: a binding proposal with acceptance criteria.
Milestone Build
The team delivers in sprints and demonstrates each milestone against its criteria. You accept or reject it before the next starts. End: accepted software and a test report.
Acceptance and Go-Live
You run user acceptance tests, we fix defects and cut over to production. End: signed acceptance and a go-live record.
Warranty and Handover
We fix any code defect or deviation from the signed specification for 60 to 90 days after go-live. End: a closed defect list and a runbook your team has used.
What We Need From You
The project depends on three decisions and the access behind them.
A Product Owner Who Decides
One person who can settle priorities, accept milestones and answer questions within the sprint.
Access to Systems and Test Environments
Accounts, API keys and test data for every system the project touches, with the security approvals your rules require.
Decisions at Each Gate
A named approver for the scope, the price, each milestone and the production cutover.
Where Fixed-Scope Projects Fail
Three failures are common. Each has a control built into the plan.
Scope Creep
New requests arrive mid-build. They go through written change control, with the cost and date effect, and you decide before work starts.
An Unknown Integration
A third-party system behaves differently from its documentation. We test the connection in the first milestone and raise the gap before it reaches the critical path.
A Dispute at Acceptance
Acceptance criteria are written before the build. If a result is unclear, we run the test, record the result and fix what fails.
What Good Looks Like
You can check these signals without asking us for an opinion.
The Acceptance Tests Pass
Every criterion has a named test, and the report shows the result before you sign.
Each Requirement Traces to Code and a Test
Your team can open the trace and see where each requirement is implemented.
Your Team Has Used the Runbook
We hand over a runbook and watch your team run one release with it.
The Defect List Is Closed
Every defect found in the warranty period is fixed or agreed in writing before the period ends.
Questions and Answers
When is a fixed-scope project the right choice?
When the outcome, the interfaces and the acceptance criteria can be written down before the build. If they cannot, Discovery and Design or a Live System Review comes first.
What happens when our requirements change?
Each change is described, priced and given a date effect. You decide whether to accept it. Nothing changes the scope, the price or the dates without your written approval.
What if the scope is not clear enough to price?
We say so before we quote. The gaps go into the Readiness Review, and you choose Discovery and Design, a Live System Review or a smaller first milestone.
What do you need from us?
A product owner who decides, access to each system and its test data, and a named approver for each milestone.
What happens after go-live?
A defect warranty of 60 to 90 days covers code defects and deviations from the signed specification. After that, you can take a managed service or run the system with your own team.
Ready to Build? Ask for a Proposal.
Send your requirements or RFP. Our architects validate them and return a binding, fixed-scope proposal.
What Happens Next
Readiness Review
In a free 48-hour Readiness Review, a Principal Architect checks your project against What we need before we start and recommends the track that fits.
Binding Proposal
After architecture validation at no cost, you receive a binding, fixed-scope proposal within 3 to 5 business days: milestones, architecture, team structure and SLAs. We sign a non-disclosure agreement (NDA) with you on request, before you share your requirements.
Mobilisation
Once you sign, our engineering pods begin Sprint 0 within 5 to 10 business days of contract signature.
Delivery in Five Stages
Mobilisation, sprints with live demonstrations, integration and hardening, acceptance and go-live, then managed services. After launch comes a warranty period, then optional support and maintenance.