Software estimates have a reputation for being unreliable. After a decade of delivering projects across 11+ industries, we understood why — and we built a system to fix it. This post explains why traditional estimation fails and how AI-assisted estimation with structured complexity assessment produces estimates that hold up.
Why Traditional Estimates Fail
The standard approach to estimation is familiar: a developer looks at a ticket, thinks about similar work they have done before, and names a number. Sometimes they are right. More often, they are optimistic.
This is not because developers are bad at estimating. It is because the process itself is flawed.
Every project contains novel problems. If the team has built the exact same feature before, in the same codebase, with the same dependencies, they can estimate it well. That almost never happens. There is always an API that behaves differently than the documentation suggests, a database schema that needs reworking, or a compatibility issue nobody anticipated.
The unhappy path is where the time goes. Estimating the happy path — the straightforward scenario where everything works — is relatively easy. The time sink is error handling, edge cases, validation, accessibility, and all the things that make software production-ready. Developers consistently underestimate this because it is invisible until you are doing it.
People confuse effort with calendar time. A feature that takes eight hours of focused development might take three days of calendar time once you account for code review, testing, context switching, and waiting for decisions. The distinction gets lost in translation.
Gut feel does not scale. A senior developer can estimate a small feature reasonably well. Ask them to estimate 30 tickets across a sprint and the accuracy drops sharply, because mental energy for careful assessment is finite.
What We Built Instead
We did not stop estimating. We replaced gut feel with a structured, AI-assisted process that consistently produces more accurate results. It is part of how we deliver projects.
Two-Stage Assessment
Every estimate goes through two stages:
Stage 1: Technical Complexity Assessment. A software architect reviews the ticket against the actual codebase — not in the abstract. This assessment considers the number of files affected, database and schema changes needed, integration points with external services, testing complexity across unit, integration, and end-to-end tests, risk of regressions, and any ambiguity in the requirements. The output is a complexity rating from trivial through to very high, with specific technical reasoning.
Stage 2: Effort Estimation. A sprint planner takes that complexity assessment and converts it into hours. Not a single number — a breakdown:
- Development — the core implementation work
- Testing — writing and running tests at the appropriate level
- Review and QA — code review, QA verification, and any rework
- Risk factor — a calculated allowance for the unknowns that always surface in real-world delivery
This breakdown matters. When a client sees “12 hours,” they understand it includes testing, review, and risk factor. These are not optional extras — they are how production-quality software gets delivered.
Confidence Levels
Not all estimates carry the same certainty. Every estimate includes a confidence rating:
- High — clear requirements, well-understood domain, the team has done this before
- Medium — some ambiguity, but standard patterns apply
- Low — significant unknowns, new territory, or underspecified requirements
A high-confidence 8-hour estimate means something different from a low-confidence 8-hour estimate. Making this explicit gives clients better information for prioritisation and budgeting.
Flags That Prevent Bad Estimates
Some tickets should not be estimated at all — at least not yet. The system flags these rather than forcing a guess:
- Needs investigation — the ticket requires a technical spike before meaningful estimation is possible
- Needs splitting — the scope is too large for a single estimate to be reliable. Break it down first.
- Blocked — a dependency must be resolved before estimation makes sense
These flags save everyone time. A forced estimate on an underspecified ticket is worse than no estimate at all, because it creates a false sense of certainty.
Why This Produces Better Estimates
The difference between this approach and traditional estimation is not marginal. It is structural.
The codebase is assessed, not imagined. Traditional estimation asks a developer to remember what the code looks like. Our process reads the actual files, identifies the integration points, and assesses the real scope. This catches the hidden complexity that gut feel misses.
Every estimate includes the full cost of delivery. Development is typically 50-60% of the work. Testing, review, QA, and risk factor make up the rest. When estimates only count development hours, they are structurally 40% too low before anyone writes a line of code.
Confidence is explicit. Instead of every estimate carrying an implied “probably,” confidence levels give clients actionable information. A low-confidence estimate is a signal to invest in requirements clarity before committing budget.
The process is consistent. A developer estimating their 30th ticket of the day will produce worse estimates than they did on the first. A structured assessment process does not get tired, does not forget to account for testing, and does not unconsciously anchor to a number someone mentioned in a meeting.
We apply this process on every engagement. If you are planning a build and want estimates you can actually rely on, talk to us.
What Clients Can Do
Even with better estimation, clients play a role in accuracy:
Prioritise ruthlessly. The fewer features in a sprint, the more accurate the estimates. When everything is a priority, the team is constantly context-switching and estimates suffer.
Invest in clear requirements. A ticket with a well-written description, acceptance criteria, and context produces a high-confidence estimate. A vague one-liner produces a low-confidence guess. The quality of the estimate directly reflects the quality of the input.
Treat early estimates as the least reliable. The estimate you get before development starts is the least informed one you will ever receive. It improves as the team learns the codebase and the client’s preferences. Do not lock in a budget based on the earliest number.
Ask about progress, not overruns. “What did we deliver this week and what is next?” is a more productive question than “Why did task 7 take two hours longer than estimated?”
Book a free 30-minute call → — no pitch, no obligation, just an honest conversation about your project.
Frequently Asked Questions
Why are software estimates so often wrong? Traditional estimates rely on gut feel and miss the full cost of delivery — testing, review, QA, and edge cases. See the section on why traditional estimates fail.
How does AI-assisted estimation work? A two-stage process: complexity assessment against the actual codebase, then effort calculation with a full breakdown. Each estimate includes a confidence level and flags for anything that needs investigation first.
Do your estimates include testing and code review? Yes. Every estimate breaks down into development, testing, review and QA, and risk factor. These are not optional — they are how we deliver production-quality software.