Almost every client fears the same thing: a quote that looks reasonable and then doubles halfway through. And almost every experienced developer knows why it happens: estimating software is genuinely hard, and unrealistic optimism is the default. Some overruns are unavoidable, but most are predictable and preventable with a disciplined approach. This article explains why estimates go wrong and how we produce estimates you can plan around.
Why estimates go wrong
- Optimism. People estimate the happy path and forget interruptions, reviews, defects, meetings and the time to understand old code.
- Hidden complexity. "A login page" or "sync with the accounting system" hides many decisions: password reset, lockouts, roles, error handling, duplicates, rate limits, rate changes.
- Unclear requirements. If nobody has defined what "done" means, the estimate is for an imagined product that differs from what is eventually built.
- Unknown unknowns. Legacy systems, undocumented APIs and data quality surprises appear only once work begins.
- Scope change. New ideas are healthy, but if they are not tracked against the budget, they silently accumulate.
- Pressure to please. Vendors sometimes quote low to win work, planning to recover money through changes; see our red flags article.
- Ignoring non-coding work: design, testing, deployment, data migration, documentation, training and project management.
Principle 1: estimate what you understand, discover what you do not
An estimate is only as good as the information behind it. For any project with real uncertainty, we recommend a paid discovery phase of a couple of weeks: interviews with users and stakeholders, workflow mapping, a review of existing systems and data, prototypes for the riskiest screens and a written scope with priorities; see our discovery phase article and how to scope an MVP. Discovery converts vague ideas into a backlog we can size and often reveals simplifications that save money.
Principle 2: break it down
Large estimates are inaccurate; small ones are more reliable. We decompose the project into features, then into tasks small enough to be understood, usually a day or two of work. Each feature includes all the work needed to make it real: design, front end, back end, database changes, tests, security checks, documentation and deployment. Estimating a feature as "5 days" without listing what it includes invites disagreement later. Breaking the work down also exposes the parts nobody has thought about.
Principle 3: use ranges, not single numbers
For each item we estimate a best case, a likely case and a worst case. The sum of many small ranges gives a total range, and the spread between them measures uncertainty. A project quoted as "between X and Y, most likely near Z" tells you far more than a false-precision single figure. Early in discovery ranges are wide; as unknowns are resolved they narrow, a phenomenon sometimes called the cone of uncertainty. Presenting ranges honestly also helps you plan your budget with a contingency.
Principle 4: write down the assumptions
Every estimate rests on assumptions, such as "the client provides content by week three," "the payment provider's sandbox works as documented," "the existing data can be imported with minimal cleaning" or "two rounds of design feedback." We list them explicitly. If an assumption proves wrong, the estimate changes, and both sides know why. Assumptions turn arguments about blame into conversations about facts; see the contract points in our article on pricing models.
Principle 5: investigate the risky parts early
For the areas of greatest uncertainty, such as an unfamiliar third-party API, a complex algorithm, performance requirements or a legacy data migration, we run a spike: a short, time-boxed experiment to learn what is really involved. A day or two of investigation can prevent a two-week surprise. Integrations are the classic example; see our integration guide and our webhooks article. Data migration is another, as explained in our spreadsheet migration article.
Principle 6: use reference projects and history
Past projects calibrate estimates. If comparable features took X hours before, that is better evidence than intuition. We keep records of estimates versus actuals and adjust our rules of thumb. Independent estimates from several team members, compared and discussed, reduce individual bias, and the disagreements point straight at hidden complexity.
Principle 7: budget for the invisible work
Real projects include time for project management and communication (our communication article), testing and bug fixing, code review, environments and deployment (CI/CD), security and performance work (security, speed), documentation and handover, and buffers for the unexpected. We include these explicitly rather than hoping they fit within the feature estimates. A typical build has a substantial share of effort outside pure "coding", and quotes that ignore it look cheap and finish expensive.
Principle 8: control change, do not fear it
Change is healthy, since you learn as you build. The danger is untracked change. We manage it with a visible backlog: each new idea is sized, and you decide whether it replaces something else, is added with a budget increase or waits. A fixed-scope phase with a clear change process, a flexible capped backlog, or a hybrid keeps you informed of the cost of each decision.
Principle 9: track and communicate against the plan
An estimate is a living document. We report progress regularly against the plan: work completed, remaining work re-estimated, hours consumed versus forecast, top risks and decisions needed. Bad news travels early, when there is still time to adjust scope, sequence or budget. Demonstrations of working software every iteration show real progress rather than percentages "complete." See also our feature flag guide for staged delivery and the retainer article for post-launch budgeting.
Where AI tools change estimates
AI-assisted development can speed up parts of the work, particularly boilerplate, tests and refactoring, but not discovery, decision-making, review, integration debugging or coordination with people. Any honest estimate accounts for both facts; see our article on low-code and AI assistants. Be sceptical of anyone promising to cut costs to a fraction simply because they use AI.
What you can do to keep your budget predictable
- Invest in discovery and a clear written scope before committing to a large build.
- Prioritise ruthlessly: separate must-haves from nice-to-haves and plan a first release with the former.
- Appoint one decision-maker who can answer questions quickly; delays in feedback cost money.
- Provide content, data and access early.
- Ask for ranges, assumptions, and what would change the number.
- Hold a contingency of ten to twenty percent, more for high-uncertainty projects.
- Review progress and budget at every iteration.
Warning signs in someone else's estimate
- A single number with no breakdown.
- No mention of testing, security, deployment, project management or post-launch support.
- Much lower than other quotes without a clear explanation.
- No stated assumptions or exclusions.
- Reluctance to explain how they arrived at the figure.
Estimating is a skill of honesty as much as arithmetic. Our software team provides ranged, assumption-based estimates after a short discovery, and reports openly against them; contact us to discuss your project. Our maintenance plans then keep the ongoing budget just as predictable.
Put this into practice with CodeLuma
CodeLuma gives ranged, assumption-based estimates broken into features, validated by early technical spikes, and tracked openly against actuals, so you see risks before they become surprises.
- Custom software development - tailored systems, integrations and internal tools.
- Website and web application development - fast, accessible, search-friendly builds.
- Maintenance and support plans - updates, monitoring and ongoing improvement.
Start a conversation. Tell us about your project and we will reply with practical next steps, or browse all CodeLuma services. CodeLuma Development Inc. is based in Nova Scotia and works with teams across Canada and remotely.
