The quote that kept growing
The quote was attractive. Much lower than the local agencies, with a delivery plan that looked tidy. Then the change requests started. The login needed two-factor authentication, which was apparently extra. The reporting screen needed filters, extra. The integration with your accounting system turned out to be more complex than assumed, extra again.
Now the project has cost well above the original figure, it is still not finished, and you are being asked to approve another estimate. You wanted cost-efficient software development. You are not sure what you have.
Why cheap quotes grow
A low quote is not always a trick. More often it reflects a scope that was underspecified on both sides.
- The brief described screens but not rules: what happens when a payment fails, who can see what, how refunds work.
- The supplier priced the happy path and treated every edge case as a change.
- Integrations were listed by name without anyone checking what the other system's API actually allows.
- Non-functional needs such as security, performance, backups and hosting were left out entirely.
- Nobody agreed how acceptance would be tested, so finished meant different things to each side.
Fixed-price contracts make this worse, not better. The supplier protects its margin by holding firmly to the literal scope, and you pay for everything the scope did not say.
What it is costing beyond the invoices
| Cost | How it shows up |
|---|---|
| Money | Change requests add up faster than the original budget allowed |
| Time | The launch keeps moving, and the business case weakens with it |
| Management attention | Hours spent arguing about what was in scope |
| Quality | Pressure to finish leads to shortcuts that cost more later |
| Options | The more you spend, the harder it feels to change course |
The last row is the sunk cost problem. It is worth looking at the remaining work on its own merits, regardless of what has already been spent.
There is also a quieter cost in the relationship itself. Once every request turns into a negotiation, people on your side stop raising small problems because it is not worth the argument. Those small problems do not go away. They turn up after launch, when fixing them is more expensive and the supplier's contract has ended.
How we get cost and scope back under control
- Independent assessment. We review the code, the original brief and the change history, and tell you what state the project is really in and what is left.
- Rewrite the remaining scope as outcomes with acceptance tests: not a screen list, but what each feature must do, including the awkward cases.
- Break it into small pieces, each one delivered to a staging environment you can test, so progress and spend are visible together.
- Price and plan pieces in order of business value. If the budget runs short, the most useful parts are already done, rather than everything being ninety percent finished.
- Include the invisible work (security, backups, deployment, monitoring) explicitly, so it is not discovered as an extra later.
- Keep everything in your repository and accounts, so you can change supplier again at any point without losing work.
This can mean we finish the project, or it can mean helping you work better with your current supplier. If the existing team is capable and the issue was the scope, fixing the scope may be enough.
What changes
You see what is being built and what it is costing as it happens. Scope discussions are about business choices, not contract wording. The remaining budget is spent on the features that matter most first. And because the code and accounts are yours, you are never trapped by what you have already spent.
Does this sound like your project?
- The project has passed its original budget and is still not finished.
- Most conversations with the supplier are about whether something was in scope.
- You cannot test progress yourself until a big delivery.
- Security, hosting or backups were never mentioned in the quote.
- You are reluctant to change course because of what has already been spent.