A complete deliverable with the scope, price and date agreed in writing before work starts. Tested in your environment and handed over so your team can run it without us.
Why fixed scope exists
Not every project needs an open-ended engagement. When the problem is clear and the deliverable can be named, you should be able to buy an outcome, not rent a team.
Fixed scope is that: a written scope, a fixed price and a fixed date, with the risk of estimation on us. When the problem is not yet clear enough for that, we will say so and suggest a discovery sprint first.
What you get
These are the commitments behind every fixed-scope project; the exact scope is agreed with your team in writing.
The deliverable, the acceptance criteria and the boundaries are agreed in writing before the first commit. What is in scope and what is out is explicit, so there is no argument later about what was promised.
What to verify: Ask to see the scope document before signing. It should name the deliverable, the acceptance tests and the exclusions.
The price is fixed for the agreed scope. If the work takes us longer than estimated, that is our problem, not yours. Changes to scope are priced separately and agreed before they start.
What to verify: Check the contract separates the fixed price from a change-request rate, and that changes need your written approval.
The delivery date is agreed up front, with milestones along the way so you can see progress weekly rather than waiting for a reveal at the end.
What to verify: Ask for the milestone plan. Each milestone should have something demonstrable, not just a status update.
The deliverable is built to run in your real environment with real users: tested, documented and deployed, not a prototype that needs rebuilding.
What to verify: Acceptance should happen in your environment against the agreed criteria, not on our staging server.
At the end you own the code, the documentation and the knowledge. Your team can maintain and extend the work without us.
What to verify: Verify the handover includes a walkthrough with your engineers and documentation they actually follow.
AI in the engagement
When the project includes AI, 'it works' becomes a testable claim with an agreed bar.
When the project includes AI, the scope names the model behaviour, the evaluation set and the accuracy bar it must pass, so 'the AI works' is a testable claim rather than a hope.
AI behaviour is measured against an agreed set of real examples before acceptance. You see the results, including the cases it gets wrong.
Where the AI touches money, customers or compliance, the scope includes the review step a human performs and the evidence trail it leaves.
From scope to handover
You see working software every week against the milestone plan, not a reveal at the end.
Working principles
Change handling, visible progress and honest fit decide whether fixed scope actually works. We make those commitments explicit rather than implied.
Real projects discover things. When scope needs to change, you get a written change request with a price and a date impact before deciding. Nothing is folded in quietly.
Every week you see working software against the milestone plan. If progress slips, you know the week it happens, not at the deadline.
One senior engineer owns the delivery and is your single point of contact. You never chase a team.
Fixed scope only works when the problem is well understood. If your problem needs discovery first, we will say so and propose a short discovery phase instead of pretending certainty.
Security & trust
The work touches your code, your data and your customers. Access, ownership and data handling are agreed in writing before the first commit.
All work happens in repositories and cloud accounts you own. If the engagement ends at any point, everything stays with you.
What we can access, at what level and for how long is agreed before work starts, and revoked when it ends.
Production data stays in your environment. Where test data is needed, it is anonymised or synthetic unless you agree otherwise in writing.
Working arrangements
The team works remotely inside your rituals, in your cloud and your repositories. On-site sessions are arranged where being in the room genuinely helps.
The team works remotely inside your rituals: your standups, your tools, your review process.
Development, staging and production all live in your cloud and your accounts from day one.
Kick-offs, discovery workshops and handover sessions can be in person where being in the room genuinely helps.
How it starts
Most fixed-scope projects start with a paid two-week sprint to de-risk the scope. If the sprint does not show real progress, you walk away.
One to two conversations to understand the problem, then a written scope: deliverable, acceptance criteria, exclusions, milestones, price and date.
The team builds against the milestone plan. You see working software every week and can redirect within the agreed scope.
The deliverable is tested against the acceptance criteria in your environment, with you. AI behaviour is measured against the agreed evaluation set.
Code, documentation and a walkthrough with your engineers. You own everything and can maintain it without us.
The sprint is a paid, time-boxed start that proves the working relationship. A fixed-scope project is a complete deliverable with an agreed price and date. Many fixed-scope projects start with a sprint to de-risk the scope.
You get a written change request with the price and date impact before deciding. The original scope and price stay intact until you approve a change.
That is our risk, not yours. The price is fixed for the agreed scope.
From the scope document: the deliverable, the integrations, the acceptance bar and the risk. You see the breakdown before signing.
Yes, and it usually makes the handover stronger. The scope names who does what so ownership stays clear.
A warranty period is agreed in the scope. After that, most clients either maintain the work themselves or continue with a pod or an ongoing partnership.
When the problem is not yet well understood, or when the real value is in ongoing iteration. In those cases we will recommend a sprint or a pod instead and say why.
Let's talk
Tell us about the problem and the constraints. We will tell you honestly whether it suits a fixed scope, and what the scope, price and date would look like.