A developer quotes you 8 weeks. Twelve weeks later, the project is 80% done. Sixteen weeks later, it's actually shipped. You're frustrated. The developer is exhausted. Both of you are slightly resentful. The relationship has soured over a 2x overrun that, statistically, was the most likely outcome from day one.
Software estimation is unreliable for reasons that don't get better with experience or seniority. The 8-week estimate isn't a lie or incompetence — it's the developer's best-case scenario, which they communicated as if it were a normal-case scenario, which is how most quotes are communicated, which is why most projects overrun.
Knowing this in advance lets you plan for the overrun without it becoming a crisis. The goal isn't to get accurate estimates (you won't). It's to budget reality, not optimism.
Why estimates are structurally optimistic
Five reasons, in rough order of how much they contribute to overrun:
1. Best-case bias
When asked "how long will this take?", developers compute the answer assuming nothing goes wrong. No bugs you didn't anticipate. No third-party API behaving weirdly. No requirement clarifications mid-project. No feedback that requires rework.
This isn't dishonesty. It's how the question is interpreted. "How long will this take?" gets answered with "how long would this take in the smooth case?" because computing the smooth case is doable; computing the realistic case requires forecasting unknowns that haven't happened yet.
The fix isn't to demand more pessimistic estimates. Developers genuinely can't compute them — they don't know what they don't know. The fix is to apply your own buffer to whatever number they give you.
2. Scope creep from your side
Mid-project, you'll request changes. You'll see V1 taking shape and realise you actually wanted a slightly different thing. You'll have a conversation with a customer that surfaces a feature you missed. The developer will accommodate these requests because they want you to be happy with the result.
Each change costs more than you think. A "small change" mid-project usually adds 1.5–3x its actual implementation time, because the developer is also re-thinking parts of what they've already built to accommodate it.
You can't fully prevent this — discoveries during a build are valuable. But you can limit it. The technique: at the start of the project, write down "the V1 scope is locked. New ideas go on the V2 list." When you have a new idea mid-build (you will), write it down on the V2 list. Don't request mid-build changes unless they're genuinely critical.
3. The 90% problem
Every software project has a "we're almost done!" moment that arrives much earlier than the actual finish line. Typically around the 70–80% mark. The remaining 20–30% takes another 50% of the calendar time.
Why: the last quarter of a project is bug fixing, edge cases, integration friction with third parties, polish. None of this shows in screenshots. The product looks done because all the visible features exist. But the invisible work — making it actually work in production with real users — takes longer than building the visible work in the first place.
The fix: when the developer says "we're 80% done," mentally bake in another 50% of the original timeline before "shipped." If the original quote was 8 weeks and you're at week 6 with the developer saying "almost there!", expect another 4 weeks before launch.
4. Integration friction
Every third-party integration in your stack adds unpredictable time. Stripe usually works smoothly. Auth0 usually works smoothly. Random HRIS API X probably doesn't have great docs and will surface 3 weeks of weird edge cases.
Senior developers price this in. Junior developers don't. The quote will be off by a factor of how many third parties are involved and how mature each is.
The fix: ask the developer specifically about each integration during scoping. "What's your experience with this API?" "What goes wrong with it?" "What's your fallback if it doesn't behave as expected?" If they wave it off ("just a few hours of work"), they haven't priced the friction. Add buffer.
5. Communication overhead
Even with a great brief, you'll have questions for the developer mid-build, and they'll have questions for you. Each question-answer cycle takes time. Most developers don't account for this in estimates — they estimate the coding time, not the project time.
The fix: ask the developer if their estimate includes communication overhead. If they say "of course," ask how much. The honest answer is usually 15–25% of the project time. If they don't have an answer, mentally add that buffer yourself.
The realistic multiplier table
Based on hundreds of projects I've watched, the practical buffer to apply:
| Developer experience | Project type | Multiplier | |---|---|---| | Senior, has shipped 5+ similar projects | Familiar territory | 1.3–1.5x | | Senior, this kind of project | Less familiar | 1.5–2x | | Mid-level, similar projects | Familiar territory | 2x | | Mid-level, new territory | Less familiar | 2.5–3x | | Junior or unknown | Anything | 3x | | Anyone | Heavy AI integration | 2.5x (the AI work is the hard part) | | Anyone | Heavy regulatory/compliance | 2.5–3x (the compliance work is unpredictable) | | Anyone | Custom commerce | 3x (don't do this; use Shopify) |
The multipliers apply to both time and money. If a senior developer quotes "$15k, 8 weeks" for familiar work, plan for "$22k, 11 weeks." If a mid-level developer quotes the same for unfamiliar work, plan for "$45k, 24 weeks."
How to communicate this without insulting the developer
Telling a developer "I'm going to plan for 2x your estimate" is going to feel like distrust. The developer is a person, and they don't want to feel like their professional opinion is being doubted from day one.
The conversation that works:
"I want to budget for both the smooth path and the bumpy path. Can we walk through the assumptions in your estimate together? Specifically: what's the biggest unknown that could push this longer? What integrations are you least sure about? What feedback might come back from V1 that we haven't planned for?"
This makes the buffer the developer's own analysis, not your distrust. They'll often add buffer themselves once you frame the conversation this way. The honest senior developers will say things like "this estimate assumes the API works as documented; if it doesn't, add 2 weeks."
You then take their adjusted estimate and add another 30–50% on top, internally, without telling them. That's the budget you actually plan against.
What to commit to externally
The buffered estimate is your internal plan. Anything you commit to externally (investor demo, customer launch, marketing campaign) should be later still.
Specific guidance:
- Internal target: developer's quote × buffer multiplier. This is when you're aiming to ship.
- External commitment: internal target + 4–6 weeks. This is when you tell investors / customers / your launch coordinator.
- Don't commit anything irreversible to the internal target. Press releases, paid ad campaigns, conference launches — these go on the external commitment date.
If the build ships at the internal target, you have 4–6 weeks of breathing room before the external commitment. If it slips to the external commitment, you've still met your obligations. If it slips past even that, you have a real problem worth flagging early — but you've avoided the situation where every slip is a customer-facing crisis.
When the developer wildly under-quotes
Sometimes a developer quotes a number so low you almost doubt it. Two possibilities:
Possibility 1: they're senior and the work is genuinely simpler than you thought. Listen to them. Senior developers have seen many similar projects and know the actual scope. Your estimate ("this should take 6 months") might be wrong because you're imagining the agency-MVP version of a build that has a 6-week tight-V1 version.
Possibility 2: they're junior and don't know what they don't know. Their quote is reasonable for the smooth-case work they understand, but they haven't realised the 90% problem, the integration friction, or the communication overhead.
How to tell which: ask follow-up questions. "What's your experience with [the specific integration]?" "Have you shipped something similar before?" "What's the biggest risk in this scope?" Senior developers answer specifically. Junior developers wave off the questions.
If the quote is suspiciously low and the answers are vague, apply the 3x multiplier and assume you're getting junior-tier execution. Either accept that and plan for the buffer, or hire a senior at higher up-front cost.
The relationship benefit of buffering correctly
Counter-intuitively, buffering correctly strengthens the developer relationship rather than damaging it.
When you've buffered and the project ships on the internal target: you're delighted, the developer feels successful, the relationship is positive.
When you've buffered and the project slips to your external commitment: you're not in crisis, the developer can do their job without panic-mode shortcuts, the relationship survives the slip.
When you've not buffered and the project slips: you panic, the developer feels pressured to ship something half-baked, you both end the project resentful, the relationship doesn't survive the next project.
The buffer is a gift to both sides. It removes the artificial deadline pressure that makes builds worse and relationships strained. The developer ships better work. You ship a better product. Nobody resents anyone.
What this means for your planning
Specific actions:
- When a developer quotes you, write down the buffered version (their quote × your multiplier). Use the buffered version for all internal planning.
- Add another 4–6 weeks for external commitments. Don't commit irreversible things to the internal version.
- Tell the developer you're planning conservatively so they don't sandbag their estimates further. The honest conversation about uncertainty is healthier than secret distrust.
- Build in a "scope freeze" agreement at the start of the project. New ideas go on a V2 list, not into mid-build changes.
- Expect the 90% point to take 50% more time than the linear extrapolation suggests.
The reward: projects that ship on or before the dates you committed to externally, which is the only metric anyone outside your project actually tracks.
What to do next
The companion articles cover the next layers of build management:
- Working With Your Developer Without Becoming a Project Manager
- Hourly vs Fixed-Price vs Retainer: Which Pricing Model for Your Build?
If you'd like a senior estimate that's been pre-buffered for the realistic case, the first call is free — see Full-Stack for SaaS Startups or Bootstrappers.
---
Part of the Full-Stack Development for Solo Founders pillar guide.