Why your software estimate doubled: 7 causes

In short: software estimates double for seven recurring reasons, and almost none of them are about programming difficulty. They are about scope that was never written down, decisions that were never made, and assumptions that were never checked. Below are the seven causes, a real example of each where I have one, and what to ask before you accept an estimate.

The seven causes

1. The scope was a conversation, not a document

Two quotes for the same app, $18,000 and $47,000, differed because the cheaper one had left out offline mode, role management and an admin back-office, about 60% of the product by effort. When the missing parts surface later, they arrive as change requests at the vendor's price.

2. A hidden architectural assumption

A vendor estimated 45 days for a multi-tenant SaaS backend, assuming a single-tenant data model. The multi-tenancy the product needed had not been priced. The gap was about 25 developer-days, a little over $12,000. See multi-tenant architecture explained.

3. Integrations behaved differently from the documentation

Third-party systems, legacy databases and payment providers have quirks. On a health-insurance platform, a legacy Oracle system could not be exposed directly, so the solution was a separate read-only API bridge with a single exposed port. That bridge was design work well beyond a simple integration task.

4. Data migration was nobody's line item

Moving existing records is rarely in the first estimate. Cleaning, mapping and checking them takes real time, and it is the most common end-of-project argument. When I migrated three years of budget history into a new system, the work was checking that balances matched the original with no drift, not copying files.

5. Error handling, permissions and edge cases were deferred

On a $90,000 build, every report was green for six sprints. Three of the six were only partially delivered: the vendor had demoed the happy path and deferred error handling, permissions and data migration to a phase that did not exist in the contract.

6. Decisions took too long

The vendor asked a question, nobody ruled, and the work continued on an assumption. Unvalidated assumptions accumulate and surface together at acceptance. Name one person who answers within two working days.

7. Scope grew without being re-costed

"While we're at it, could it also…" is the most common cause of overruns. Each addition needs a stated impact on date and budget before it is accepted, even if the answer is yes.

What to ask before accepting an estimate

What are the written assumptions behind this number?
Which of my requirements are not covered, and what is explicitly out of scope?
How are migration, testing, security and the admin back-office priced?
How is a change request costed, and who approves it?
What would make this estimate wrong?

How to prevent it

Write the scope with ranked requirements and acceptance criteria before asking for quotes.
Compare quotes against the same document (see how to compare quotes line by line).
Grade each sprint against written criteria. Build Oversight does this on the client's side.
If a project is already running and the estimate has slipped, a Delivery Risk Audit shows where and how much.