Fixed price, fixed date: how we make it work
What should you know about fixed price software delivery, and how does a vendor make a fixed date hold?
Fixed price works because scope is locked early, change goes to a priced backlog and hardening has its own week. Every Eazyware program has a fixed fee, a fixed calendar and an evaluation threshold that defines done, and the method behind that is a set of unglamorous habits rather than heroics near the deadline.
Fixed price software delivery has a bad reputation, and it earned it. The usual version is a vendor who guesses low, discovers the real scope in month two, and then either eats the loss and cuts corners or reopens the price and the date. We have run fixed price, fixed date programs for years, including AI work where the technology itself is uncertain, and they hold because of a method rather than optimism. This article describes that method: how scope gets locked, where change goes, why hardening has its own week, and what we do when something is genuinely unknowable.
Why fixed price fails elsewhere
Three things break most fixed-price projects. The scope was never written down precisely enough to defend, so every conversation adds to it. Change was handled by argument rather than by a mechanism, so both sides spent energy on who was right instead of what to do. And testing, deployment and the last ten percent were assumed to fit in the gaps, so the date slipped in the final week. Each of those has a specific countermeasure, and the countermeasures are what you are buying when you buy a fixed program.
The method in one table
| Failure mode | Our countermeasure | When it happens |
|---|---|---|
| Vague scope | Sprint Zero produces a scope document with explicit exclusions and an evaluation threshold that defines done | Before the build is priced |
| Scope creep by conversation | Scope lock: nothing enters the build that is not in the document; new ideas go to the priced backlog | Week one onwards |
| Unpriced change | Every backlog item is estimated and priced within two working days; the client chooses to swap, defer or add at cost | Continuously |
| Last-week crunch | Hardening week: no new features, only evaluation, security, performance and deployment | The final week of every program |
| Technical unknowns | A spike in Sprint Zero on the riskiest assumption before the price is set | Before commitment |
| Client dependencies | Named client tasks with dates in the plan; a missed dependency shifts the date by the same number of days, visibly | Agreed at kick-off |
The scope lock method
Scope is a document, not a conversation
Every program starts from a scope document: what is in, what is explicitly out, the interfaces to existing systems, the data we will receive and when, and the evaluation threshold that means done. The exclusions are as important as the inclusions. "Mobile is out of scope" written down in week zero prevents a week-four conversation that begins with "obviously we assumed". The document is short, usually a few pages, and both sides sign it. We wrote about the discipline itself in scope lock: the discipline that makes fast MVPs possible.
The build works only from the document
Once the build starts, the team implements what the document says and nothing else. That sounds rigid; in practice it is what makes the team fast, because nobody is re-planning mid-sprint. The client sees working software every week, which is where new ideas come from, and those ideas are welcome. They just do not go into the build directly.
Where change goes: the priced backlog
New ideas, discovered requirements and changed minds go to a backlog. Within two working days each item gets an estimate and a price. The client then has three choices: swap it for something of similar size that is still unbuilt, defer it to after launch, or add it at the quoted price with the date moved by the quoted days. There is no fourth option where it is squeezed in for free, because that option is how fixed dates die. Clients sometimes find the first swap conversation uncomfortable and the fourth one liberating: the trade-offs are visible and theirs to make.
Why hardening has its own week
The final week of every program is closed to features. It is spent running the full evaluation suite, fixing regressions, load-testing the paths that matter, closing security findings, writing the runbook and rehearsing the deployment with the client's engineer at the keyboard. Teams that skip this week ship on the date and spend the following month firefighting; we would rather ship one fewer feature and have the client's first month be quiet. For AI features, hardening is also when shadow-mode results are reviewed and the release gate is set. The from POC to production checklist lists what that week covers.
Handling what is genuinely unknown
AI projects contain questions that cannot be answered by planning: will the model read these documents accurately, will retrieval find the right passage, will the voice model cope with this accent. We do not price those into a fixed build on hope. Sprint Zero runs a spike on the riskiest one, and the ProofRun program exists to answer a bigger question in three weeks with a pass mark agreed in advance. Only when the risk is measured do we quote a fixed Launch 6 or ReCore. The programs and their prices are on the pricing page; a Sprint Zero is $3,250 or ₹2,00,000 and is credited against the build that follows.
A fixed date is a promise about behaviour, not a prediction about luck. The behaviour is: lock, price, harden.
What the client commits to
Fixed price is a two-sided contract. The client commits to named people who can make decisions within a day, to delivering data and access on the dates in the plan, and to reviewing each week's software promptly. When a client dependency slips, the date moves by the same number of days, and we say so in writing that week rather than absorbing it silently and surprising everyone at the end. This is not a penalty; it is the only way to keep the plan true.
A worked example
A last-mile logistics operator needed a dispatch platform and an offline-first driver app on a fixed date tied to a contract with a large customer. Sprint Zero produced a scope document that put automated route optimisation out of scope for launch and manual dispatch with rules in. In week three the operations team asked for proof-of-delivery photos with a signature; it was priced within two days and swapped for a reporting screen that could wait. In week five a payment-gateway dependency on the client side slipped by four days, and the launch moved by four days, announced that week. Hardening week found a sync conflict in the offline app that would have been a launch-day incident. The platform shipped on the adjusted date, and route optimisation was built afterwards from the backlog. The outline is in the dispatch platform case study.
Team and timeline
Every program is a fixed team for a fixed calendar: Sprint Zero is ten working days; ProofRun is three weeks at $6,250 to $10,500; Launch 6 is six weeks at $26,500 to $45,500 (from ₹17,60,000) with hardening in week six; ReCore modernisation runs eight to sixteen weeks from $31,500 with a hardening week per release. Service builds such as product and platform development follow the same method with the calendar set in Sprint Zero. After launch, the priced backlog continues under a Care Plan or a follow-on program, so the fixed date is the start of a roadmap rather than the end of a relationship.
Before you start: a checklist
- Insist on a written scope with explicit exclusions before any price is quoted
- Ask for the evaluation or acceptance threshold that will define done
- Agree the change mechanism in advance: swap, defer or add at price
- Confirm there is a hardening week with no feature work in it
- Name your decision-maker and confirm they can answer within a day
- List the data, access and third-party dependencies you owe, with dates
- Ask how the vendor handles a slipped client dependency, and get it in writing
- Decide what happens to the backlog after launch
Glossary
- Scope lock: the point after which the build implements only the signed scope document
- Priced backlog: the list of requested changes, each with an estimate and a price, from which the client swaps, defers or adds
- Hardening week: the final week of a program, reserved for evaluation, security, performance and deployment rehearsal
- Spike: a short, time-boxed technical test of the riskiest assumption, run before a price is set
- Client dependency: a task, data set or access the client owes on a date, tracked in the plan
Questions clients ask
- What if you underestimate? We absorb it. The price does not move for our mistakes; it moves only for scope you add or dependencies that slip on your side.
- Can we change the scope after signing? Yes, through the backlog. Swaps of similar size cost nothing; additions are priced before you decide.
- Is fixed price more expensive than time and materials? It carries a margin for risk, which is why we reduce the risk first with Sprint Zero. The comparison is in fixed price vs time and materials for AI projects.
- What if the AI part does not reach the threshold? That is what ProofRun is for. If a POC misses its pass mark, you have the evidence and the build is not started.
Related reading
See fixed price AI development: how it works and when it fits and our wider stance on the about page. Martin Fowler's writing on fixed-scope and fixed-price contracts sets out the classic objections we designed the method to answer.
Fixed price is not a bet on estimating well; it is a set of habits that make the estimate defensible, and those habits are what you should ask any vendor to show you.
Frequently asked questions
What is the scope lock method?
▾
A written scope with explicit exclusions and an acceptance threshold, signed before the build, after which nothing enters the build except through a priced backlog where the client chooses to swap, defer or add at cost.
Does fixed date delivery mean features get cut?
▾
Sometimes, by choice. When something new matters more than something unbuilt, the client swaps them. The date holds because the trade is explicit rather than because the team works nights.
How does fixed price work for AI projects with technical uncertainty?
▾
The uncertainty is measured first in a Sprint Zero spike or a ProofRun with a pass mark, and only then is the build priced. We do not quote a fixed build on an assumption we have not tested.