Software Development Estimation: Why Quotes Miss (2026)

Why Fora Soft wrote this estimation playbook

Software development estimation is the most consequential conversation a buyer has with a vendor. The number you sign sets the budget, the runway, the team size, and the promise you make to your board or your customer. And the industry has been bad at it for forty years, with the data to prove it.

Fora Soft is a specialist software house for video, real-time, and AI products — 50 in-house engineers, 250+ projects shipped since 2005. We’ve been on both sides of the estimation conversation that whole time: we’ve written hundreds of estimates that held, lived through the few that didn’t, and audited dozens more that buyers brought us for a second opinion. The same red flags repeat: a single round number, no assumptions, no line for testing, a salesperson who can’t name three risks. The pattern is consistent. So is the fix. This playbook is written by the engineers who scope and ship that work, not a marketing desk.

This is the playbook we wish every buyer had before comparing three competing quotes for the first time. It explains why estimates legitimately differ, what an honest one contains, the common failure modes, and the questions to ask before you sign anything. Proof of the discipline, not adjectives: CirrusMED shipped a HIPAA telehealth MVP on the budget we wrote in week one; BrainCert launched its WebRTC classroom against the original milestones; Perspire.tv hit its first paid release on the schedule the estimate promised. Same method on all three, and it’s the method this article hands you. If you want it applied to your own build, that’s our custom software development practice.

Why three vendors quote three different numbers

When the same brief gets a $40k quote, an $85k quote, and a $180k quote, none of them is necessarily lying. Each is answering a different question inside its own head.

Different scope assumptions. One vendor read “simple chat” as a single message thread; another read it as multi-room with presence and read-receipts; the third read it as moderated chat with audit logs. The brief didn’t specify, so their assumptions filled the gap differently.

Different non-coding allowances. Coding is 40–60% of a real project. Testing, code review, design, deployment, and documentation are the rest. The cheap quote often forgot half of those line items; the expensive quote priced them in.

Different team rates and seniority mix. A senior architect at $180/hr who ships in two weeks beats a junior at $40/hr who ships in eight, even though the line-item rate looks worse. Total cost is what you’re comparing, not the hourly.

Different risk margins. A defensible estimate carries a 15–30% buffer for unknowns. The cheap quote often carries 0%. You pay that buffer back later through change orders, missed deadlines, or a quietly extended bill.

Different sales philosophy. Some shops bid low to win and recoup margin through change requests. Some bid high because they have a waitlist. Some bid honestly. Telling them apart is the rest of this article.

The data: how often estimates miss, and by how much

Here’s the short version before the numbers: most software projects miss their estimate, and the ones that miss badly miss by a lot. That’s not a reason to skip estimating. It’s a reason to estimate as a range and manage the range.

The Standish Group CHAOS reports have tracked IT outcomes for three decades. The long-running split: roughly 31% of projects succeed (on time, on budget, scope intact), about 50% are challenged (late, over budget, or de-scoped to ship), and around 19% are cancelled. Small projects do far better; large ones do far worse, which is the single strongest argument for slicing scope small.

McKinsey’s research with the University of Oxford (5,400+ projects, 2012) found that large IT projects — those over $15M — run 45% over budget and 7% over time on average, while delivering 56% less value than promised. About 17% go so badly they threaten the existence of the company that commissioned them.

The scarier finding sits in the tail. In their Harvard Business Review study “Why Your IT Project May Be Riskier Than You Think” (September 2011), Bent Flyvbjerg and Alexander Budzier analysed 1,471 IT projects: the average cost overrun was a manageable 27%, but one in six was a “black swan” with a 200% average cost overrun and a 70% schedule overrun. Averages hide the risk; the outliers are where companies get hurt.

There’s a lever, though. PMI’s 2025 Pulse of the Profession found that projects led by managers with high business acumen hit 73% budget adherence versus 68% for the rest, with the failure rate dropping from 11% to 8%. Not a miracle, but proof that who runs the estimate matters as much as the spreadsheet behind it.

The Cone of Uncertainty: estimates have a legal range

Steve McConnell’s Software Estimation: Demystifying the Black Art gives the single most useful concept in this conversation: the Cone of Uncertainty. At project kickoff, with only an idea and no requirements, the best possible estimate still spans roughly 0.25× to 4× the eventual number. Once requirements are complete, the spread narrows to about ±1.6×. After detailed design, about ±1.25×.

Figure 1. The wider the cone, the less scope is fixed. A $100k build at concept stage can honestly price anywhere from $25k to $400k.

Translation: a $100k project at the concept stage could be honestly priced anywhere from $25k to $400k. That spread doesn’t mean the estimator is bad; it means the scope is genuinely undefined. Asking for tighter precision before you’ve fixed scope is asking for a guess dressed as a number.

Your job as the buyer is to push the project into the narrow end of the cone before you sign — through a discovery phase, a wireframe pass, or a written spec. The vendor’s job is to say which part of the cone the number lives in. A fixed-price quote at kickoff with three significant figures is the antipattern; “$80k–$140k pending design freeze” is the honest version.

Three estimate types: match the type to the decision

The AACE International cost-estimate classification (standard in engineering, and used for serious software work) defines three you should be able to name out loud.

1. Rough Order of Magnitude (ROM, AACE Class 5). Accuracy band roughly −50% / +100%, used at 0–5% scope definition. The right answer for “is this even feasible at our budget?” The wrong answer for “sign here.”

2. Budget Estimate (AACE Class 3). Accuracy band roughly ±15–30%, prepared at about 30–40% design completion. This is the estimate type that should drive your actual budget allocation, and most signed contracts belong here.

3. Definitive Estimate (AACE Class 1). Accuracy band roughly ±5–15%, requiring more than 80% detailed design. Achievable only late in planning. A vendor offering Class 1 accuracy at kickoff is over-promising.

Estimate types compared: what each one is for

A condensed view of when each estimate type fits, the accuracy you can expect, and the decision it should drive.

The estimation techniques behind a real number

When a vendor hands you a number, it helps to know which technique produced it. Each has a place, and each fails in a specific way.

Bottom-up (work breakdown structure). Decompose the project into tasks, estimate each in hours, sum. The most accurate technique once scope is reasonable. Labor-intensive but defensible.

Top-down (analogy). Compare to past similar projects. Fast, but biased by which past project you pick. Good as a sanity check on bottom-up, dangerous as the primary method.

Three-point / PERT. Estimate optimistic, most likely, and pessimistic, then weight as (O + 4M + P) / 6. Surfaces variance instead of hiding it. Pairs well with bottom-up.

Planning poker / story points. Agile teams size user stories by consensus using Fibonacci values (1, 2, 3, 5, 8, 13). Captures disagreement and forces the team to say out loud why estimates differ.

T-shirt sizing. A quick S / M / L / XL pass for early triage. Useful in roadmap talks; not signing-grade.

Function points / COCOMO II. Algorithmic models that derive effort from feature counts and complexity factors. Heavy machinery, worth it on enterprise and regulated work.

Ten reasons software estimates legitimately fail

Most misses aren’t incompetence. They’re a short list of predictable causes, and knowing them turns you into a sharper reader of any quote.

1. Underspecified requirements and scope creep. PMI puts scope creep at about 52% of projects. Each change feels small; the cumulative effect is a different product than the one estimated.

2. Hidden complexity in third-party APIs. The Stripe webhook that needs an idempotency layer. The Salesforce sync that needs three custom fields. Estimates routinely under-budget integration work by 30–50%.

3. Wishful thinking and sales pressure. The salesperson promises the timeline that wins the contract; the engineering team inherits an impossible commitment. The fix is to put the delivery team in the room before the number is signed.

4. The pad-then-strip antipattern. The developer adds 50% to cover unknowns; the manager cuts 30% because “that looks like padding.” The signed number is now under-funded by 20% before work starts. Both sides should declare their buffer in writing.

5. Missing testing, review, and refactoring. Coding is 40–60% of a real project; testing is 20–30%; review, deployment, security checks, and the inevitable refactor are the rest. Estimates that show only “dev hours” under-budget by half.

Figure 2. Where the hours actually go. If a proposal shows one “development” line, roughly half the real work is hidden.

6. Unaccounted non-coding work. Standups, design reviews, stakeholder demos, deployment runs, documentation, support handoff. Developers spend a minority of their time writing code, and the estimate has to price the rest.

7. Optimism bias on productivity. Everyone thinks they’re a 10× engineer. The math has to assume average performance under the team’s real conditions, not the best week of the senior’s life. Kahneman and Tversky named this the planning fallacy in 1979, and software hasn’t outgrown it.

8. Brooks’s Law — communication overhead. Three engineers carry three communication channels; six carry fifteen. Adding people late to a slipping project usually slows it down. The estimate must reflect team size, not just total hours.

9. Unfamiliar stack or first-time integrations. A team writing its first WebRTC implementation or first HIPAA audit log will find the surprises in production, not in the estimate. Allow a 20–40% premium on first-time-on-stack work.

10. Compliance and regulatory cost. HIPAA, SOC 2, GDPR, PCI-DSS, accessibility. The posture is often invisible until the audit fails. Honest estimates put a separate line item with hours, evidence requirements, and a named owner.

What an honest software estimate actually contains

A defensible estimate is a document, not a number. Here’s the structure we use, and the structure you should expect from any vendor worth signing.

Figure 3. The six parts of a defensible proposal. If one is missing, ask for it before you sign.

1. Assumptions. What scope was assumed, which integrations were treated as ready versus build, which platforms are in, which user types are out for now. Five to fifteen items is normal.

2. Risks and dependencies. Three to seven named risks, each with a probability and a mitigation, plus the dependencies on the buyer (sample data, decision authority, third-party access) stated explicitly.

3. Work breakdown. Hours per role: design, front-end, back-end, QA, DevOps, project management. The cheap-quote tell is “dev hours” as a single line; the honest version separates them.

4. Range, not a single number. Low, most likely, high. Three-point or PERT estimation surfaces the variance. A single number is signing without information.

5. Milestones and deliverables. A demo cadence (every two weeks is the modern default), a working build at each milestone, and the deliverable you can put in front of a customer or investor by a named date.

6. Buyer’s responsibilities. The estimate is a two-sided contract. Provide assets by date Y, decide on copy by date Z, hand over API credentials by date W. If the buyer slips, the schedule slips, and that should be in writing on both sides.

Worked example: from hours to a defensible number

Abstract advice is easy to nod at, so here’s the arithmetic on a real shape of project: a 1-on-1 video MVP with recording, basic chat, and payments, on web, iOS, and Android. Watch how hours become a number.

A bottom-up breakdown lands near 2,360 hours. Three-point estimation puts the low at 2,000 hours (scope holds, integrations behave), the high at 2,900 hours (real-time video surprises us on iOS), and applies the PERT weighting: (2,000 + 4 × 2,360 + 2,900) / 6 ≈ 2,400 hours.

Now convert to money. At a blended $55–$75/hr — sustainable rates for a mixed senior/mid team in 2026 — that’s 2,400 × $55 = $132,000 on the low end and 2,400 × $75 = $180,000 on the high end. So the honest quote is “$132k–$180k, most likely near $150k, pending a design freeze,” not “$149,000.”

Figure 4. The buyer signs the range and the assumptions, not a lone three-figure number.

The point isn’t the exact dollars — yours will differ with scope and rate. The point is that every step is inspectable: hours, weighting, rate, range. A quote you can’t take apart like this is a quote you can’t trust.

Fixed price vs T&M vs hybrid: match your risk profile

Fixed price. The vendor bears scope and timeline risk; you get predictability. It hides a 15–30% risk premium in the quote (otherwise the vendor loses money on the unknowns). Right when scope is genuinely locked — rare — and painful when it isn’t, because the vendor recovers margin by cutting testing or quality.

Time and Materials (T&M). You bear the risk; the vendor is paid for hours worked. Aligns the vendor with quality and transparency, but needs an active product owner on your side. Without that oversight, T&M is just open-ended billing.

Hybrid (target with cap). An agreed target price plus a cap; overruns are shared or absorbed by the vendor up to a defined limit. Keeps both sides honest about staying in budget while leaving room for genuine surprises. It’s the most common 2026 default for serious work.

Per-sprint or outcomes-based. Pay sprint by sprint against agreed deliverables, or tie compensation to business outcomes like uptime or conversion lift. Newer, and it needs high trust plus good metrics. Right for established partnerships, not first engagements.

Eight red flags in a proposal (and the questions that surface them)

1. Single-point estimate with no range. Ask: “What’s your low and high, and why?” If they can’t answer, the number is a guess.

2. Estimate identical to a competitor’s. Suggests copying, not analysis. Ask each vendor for their five biggest assumptions and compare the lists.

3. No breakdown of design / dev / QA / PM. Ask for the hours per role. The honest answer fits in a one-page table.

4. No testing or buffer line. Ask: “What percent of the budget is QA, code review, and contingency?” A healthy answer is 20–40% combined.

5. Hourly rate too low to be sustainable. Below about $50/hr in 2026, the work is usually offshore juniors with thin oversight; below $30/hr it’s a coin-flip on quality. The cheap rate often costs more after the rework.

6. The salesperson can’t explain the assumptions. Ask the salesperson for the three biggest risks. If they hand you back to engineering, engineering should be in the room from the next call on.

7. “We’ll figure it out as we go.” Translation: scope creep, change orders, no commitment to a number. Acceptable only on T&M with weekly demos and an active product owner, never on fixed-price.

8. Fixed-price proposal with vague scope language. “Reasonable iterations.” “Standard integrations.” “Best-effort QA.” Each phrase is a future change-order ambush. Demand exact specs or move to T&M with a cap.

How AI tooling changed software estimates in 2026

Does AI make estimates lower? On routine work, yes; on the hard parts, barely. That distinction is the whole answer, and a vendor who blurs it is selling.

Agent Engineering and AI code assistants have compressed the routine parts of software work. Top coding agents now resolve more than 70% of well-scoped issues on the SWE-bench Verified benchmark as of 2026, and senior engineers using them report real weekly savings on refactors, debugging, and boilerplate.

The practical effect: a senior engineer with modern tooling can ship scope in 2026 that would have needed two engineers in 2020. We see it on every project we run, and it’s part of why our estimates beat 2020-era industry benchmarks. The buyer-side implication is simple — if a vendor’s 2026 quote uses 2020 hourly assumptions without acknowledging tooling gains, they’re pricing the wrong year.

Here’s the honest counter-point. AI accelerates routine work, not unfamiliar work. Compliance, integrations, ambiguous requirements, and design decisions still take about the same time. The savings show up on the dev-hours line; the design and PM lines stay roughly flat. A vendor claiming “AI cuts everything in half” is over-selling. A vendor claiming “AI cuts the dev line 30–40% on routine tasks” is being straight with you.

Mini case: how Fora Soft writes an estimate

A concrete proof of pattern. When CirrusMED came to us for a HIPAA telehealth build, here’s the rough shape of the estimate we wrote — numbers approximate, structure verbatim.

Scope. Video visits with recording, secure messaging, scheduling, and payments, on web plus iOS and Android. Three user types. Eight integration points. Compliance: HIPAA from day one, SOC 2 path later.

Work breakdown. Discovery 80h. Product design 200h. Front-end web 320h. iOS 280h. Android 280h. Back-end and APIs 360h. Real-time video 200h. Recording and storage 120h. QA 240h. DevOps and deployment 80h. Project management 200h. Total 2,360h.

Range. Low 2,000h if scope holds and integrations are smooth, most likely 2,360h, high 2,900h if the video layer surprises us. PERT-weighted central estimate about 2,400h — the same arithmetic as Figure 4.

Assumptions. Sample data and brand assets by week 2. Decision authority responds within 48 hours. HIPAA-eligible infrastructure and a signed BAA with the video provider. iOS 16+ and Android API 28+.

Risks. Real-time video on iOS can surface AVFoundation surprises (mitigation: 40h buffer in the iOS line). HIPAA evidence collection often runs longer than scoped (mitigation: a separate evidence track with a named owner). The domain depth here comes from projects like this one — our video streaming engineering guide is the same knowledge in longer form.

Buyer’s responsibilities. Sample assets, a payment processor account, App Store accounts, and a decision SLA. The signed estimate carries a small table of buyer-side line items and dates. If the buyer slips, the schedule slips, and the estimate is re-cut on a documented change. Want a similar estimate for your project?

A buyer’s decision framework in five questions

Run any proposal through these five. If you get five clean answers, you can sign with confidence.

Q1. Is the scope clear enough for a Class 3 estimate? If you can’t describe the user, the workflow, and the integrations in one page, you’re still at Class 5 (ROM). Run a paid discovery sprint first, then sign on the budget estimate.

Q2. Did the proposal name three risks? If yes, the vendor has thought about your project. If no, the number is generic.

Q3. Does the work breakdown show design / dev / QA / PM as separate lines? If yes, the math is defensible. If no, the math is hidden.

Q4. Is the buffer 15–30% of the total? Below 15% is wishful; above 30% means scope is too unclear to commit yet, which is a signal to scope first.

Q5. Will the team that delivers be the team in this scoping call? If yes, the estimate has accountability. If it’s “we’ll match you with a delivery team after signing,” you’re signing for an unknown team’s assumptions.

When NOT to trust the lowest quote

The short answer: whenever the low number was bought with something you’ll pay for later. Cheap is a strategy, and sometimes it’s the wrong one for you. A few situations where the lowest quote is the one to walk away from.

When it skips testing to hit the price. A quote that’s 40% under the others usually got there by dropping QA, code review, or security. On a payments or healthcare product, that saving becomes an incident. Don’t optimise the number that shows; optimise the total cost of ownership.

When your scope is still moving. A fixed low price on an exploratory MVP guarantees change-order friction the moment you learn something. If you’re still discovering the product, a T&M or capped-hybrid arrangement protects you better than the cheapest fixed bid.

When the discount comes from juniors with no oversight. A $28/hr blended rate isn’t magic; it’s inexperience without review. The rework, the missed edge cases, and the architecture you’ll rebuild in year two erase the saving. Honest beats cheap, and it’s not close.

KPIs to monitor once the build is running

An estimate is a living document. These four numbers tell you early whether it’s holding.

Schedule variance. Actual hours vs planned hours per milestone. The first 20% of a project predicts the rest with surprising accuracy — if you’re 30% over hours by milestone two, you’ll be about 30% over budget at the end.

Scope-change rate. The number and size of change orders per month. A healthy project has fewer than two material changes per month after design freeze; more than that is scope creep, and the estimate should be re-cut, not absorbed.

Defect density. Bugs per delivered feature (or per thousand lines). A vendor that under-quoted QA will surface here within four weeks of beta.

Demo cadence. A working build at every demo. If the demo slips or the build is broken, the schedule is slipping too — raise it the same week, not at month end.

Frequently asked questions

Why does software development estimation miss so often after forty years?

Three reasons. Software is creative work with embedded uncertainty, so you can’t fully estimate what you haven’t designed. The planning fallacy (Kahneman and Tversky) biases people toward optimism. And sales pressure rewards low quotes that win contracts even when engineering would price higher. The fix is process discipline — the Cone of Uncertainty, three-point estimation, Class-3 budget estimates — plus the honesty to say “we don’t know yet.”

Should I always pick the cheapest estimate?

No. Cheap estimates often skip testing, code review, compliance, or buffer, and the total cost ends up higher after rework and change orders. Compare estimates on the work-breakdown line items, not the bottom-line number. Reject the lowest if it doesn’t name testing, QA, and contingency as separate lines.

What’s a fair buffer percentage in 2026?

15–30% of total hours, depending on scope clarity. Less than 15% is wishful; more than 30% means the scope is too unclear to commit, so a discovery phase beats a padded number. The buffer should be transparent in the estimate, not buried inside per-line items.

Fixed price or T&M — which is better?

Neither universally. Fixed price fits when scope is genuinely locked and you want predictability; T&M fits when scope will evolve and you have an active product owner. The 2026 default for serious work is hybrid — a target cost with a cap, both sides sharing overage and savings. That aligns incentives without trapping either party.

How do I read three competing quotes at $40k / $85k / $180k?

Reconcile their assumptions. Ask each vendor for a five-line scope summary, a work-breakdown table, and their three biggest risks. The cheap quote almost always assumed less scope or less rigor; the expensive one usually priced more line items. Once the scope assumptions match, compare hours by role and the spread narrows sharply. We run this exercise for buyers as a paid second opinion.

Do AI coding tools really make estimates lower?

On routine work, yes — 30–40% compression on coding hours is realistic for senior engineers using modern AI assistants. On unfamiliar work (compliance, integrations, ambiguous requirements, design), the savings are small. An honest 2026 estimate shows a lower dev-hours line than the 2020 equivalent, but roughly the same design, PM, and QA lines. “AI cuts everything in half” is a sales line; “AI cuts dev hours 30–40% on routine tasks” is the truth.

What’s the difference between an estimate and a quote?

An estimate is a probabilistic prediction with a range; a quote is a binding commitment. Estimates are right at the ROM and Budget stages; quotes belong at the Definitive stage, after detailed design. Treating an early estimate as a binding quote is one of the biggest sources of project disputes, so make sure both sides know which one they’re signing.

How do I keep an estimate honest after we sign?

Weekly status with hours-burned vs hours-planned. A two-week demo cadence with a working build. A change-order log with explicit cost and schedule impact for any new scope. Monthly retros comparing actuals to plan. The estimate is a living document, not a one-time signing, and the vendor should propose this cadence in the original proposal. If they don’t, ask for it.

What to read next

Ready to compare estimates honestly?

Software development estimation will keep being hard because software is creative work with embedded uncertainty. The fix isn’t a better algorithm; it’s better discipline. Use the Cone of Uncertainty to know which estimate type you’re reading. Use three-point estimation to surface variance. Demand a work breakdown, named risks, and explicit assumptions. Reject single-number quotes from sales teams that can’t explain their math.

If proposals are on your desk and the spread doesn’t make sense, the most useful next step is a 30-minute audit with senior engineers who write estimates every week. We’ll mark the assumptions, find the missing line items, and tell you what to ask each vendor. The goal isn’t to win your contract — it’s to make sure the one you sign is a contract you can actually deliver against.