How long does software take to build?

Understanding a realistic software development timeline starts with why every founder has been told six weeks and received four months. It is tempting to conclude that engineers are bad at estimating, or optimistic, or being deliberately vague.

The real explanation is structural, and once you see it the planning problem becomes tractable.

Why estimates skew one way

If estimates were merely imprecise, they would be wrong in both directions and average out. They do not. They are consistently short, and the reason is that the work you discover is nearly always additional.

You find out the API you are integrating with has no sandbox. You find out two requirements conflict. You find out the client's data has a shape nobody mentioned. You almost never discover that something is unnecessary.

So the error distribution is one-sided. Any estimate produced without accounting for that is a best case being reported as an expectation.

What actually determines the timeline

Scope, obviously. But specifically the scope nobody wrote down. Undocumented assumptions become work at the point somebody notices them.

Integrations you do not control. Access, credentials, sandbox environments, undocumented behaviour, support tickets that take a fortnight. This is the most under-estimated category in almost every plan.

Decision latency on your side. This is the one nobody puts in the plan and it is frequently the largest. If a question takes five days to answer because the person who can answer it is busy, and there are twenty such questions, that is a hundred days of partial blockage in a project you estimated at sixty.

How well the ground is prepared. Environments, access, test data, a person who can answer questions. A team waiting for a VPN account is a team not building anything.

Requirement conflicts. Two stakeholders wanted incompatible things and nobody noticed until it was implemented.

Notice that "how fast engineers write code" is not on this list. It is the part everyone optimises and it is rarely the constraint — which is also why adding people to a late project reliably makes it later.

What AI changed, and what it did not

Implementation is faster. That is real, and it has genuinely compressed the build portion of a timeline.

Be careful about extrapolating it to the whole. METR's randomised trial found experienced developers were 19% slower on tasks in codebases they knew well while believing they were 20% faster — a useful caution against planning from perceived speedups. DORA's 2025 data found AI adoption correlating with higher throughput and higher instability together: faster delivery, more rework.

The practical planning consequence: the code-writing portion has shrunk, everything around it has not, and some of the gain returns as review and rework. Expect a meaningfully shorter build phase, not a shorter project by the same proportion.

A worked timeline, week by week

Ranges are less useful than seeing where the weeks actually go, so here is a real shape for a multi-role product build — a supplier portal with authentication, three workflows and role-based permissions, the kind of project that reliably gets estimated at ten weeks and reliably takes fourteen.

Weeks 1–2: scoping and specification. Outcome, constraints, non-goals and acceptance criteria written and agreed. This is where the biggest source of later delay gets removed before it can cause any — every ambiguity resolved here is a delay avoided in week nine.

Weeks 3–5: core workflow one, deployed. The primary user journey, end to end, behind a feature flag, tested against realistic data. This milestone is deliberately the hardest one, because the data model and the core patterns get established here — everything after moves faster because the foundation is set.

Weeks 6–7: core workflow two, plus the permission layer. Now that the pattern exists, a second workflow is faster to build than the first. Permissions get layered in once there are at least two workflows to apply them to, which is intentionally later than founders usually expect — building permissions before there is anything to permission tends to produce a permission system shaped by guesswork rather than by real usage patterns.

Week 8: the integration nobody scoped precisely. In this shape of project, there is almost always one external system whose behaviour was not fully known at estimation time — in this example, a supplier's existing inventory system with an undocumented rate limit discovered only once real load testing began. This single week absorbs what would otherwise be the single largest source of overrun, precisely because it was budgeted as an unknown rather than assumed away.

Weeks 9–10: workflow three, admin tooling. The remaining core workflow, plus whatever minimal admin surface the internal team genuinely needs — not the full admin panel imagined at the start, because by this point real usage has clarified which parts of it actually matter.

Weeks 11–12: launch hardening. Error states, empty states, monitoring, the sign-up flow polished for a first-time user rather than the internal team who has been testing it for ten weeks. This phase is the one most often left out of an initial estimate entirely, and it is never actually optional.

Weeks 13–14: stabilisation. The two weeks after real users arrive, absorbing the bugs no test suite caught and the small changes the first week of feedback demands.

Fourteen weeks, not ten — and the four extra weeks are not evidence of poor estimation. They are the integration unknown, properly budgeted rather than assumed away, plus the hardening and stabilisation phases that a ten-week estimate simply omitted because they do not appear in a feature list and nobody demos them.

Rough shapes

Assuming a competent team and decisions that arrive within a day or two:

That last row is worth noting. The gap between "it works" and "it is ready for real users" is consistently underestimated, because it consists of unglamorous work — error states, empty states, monitoring, the sign-up flow — that nobody demos.

How to plan honestly

Ask for a range with reasons. "Six to ten weeks, and here is what determines which end" contains far more information than "eight weeks".

Ask what would make it wrong. This surfaces specific risks you can act on, rather than a buffer you cannot inspect.

Track actuals against estimates. Two months of this data tells you your team's specific bias — most teams are consistently off by a stable factor, and knowing yours is worth more than any estimation methodology.

Re-estimate at milestones. An estimate made when 20% is complete is dramatically better than one made at zero. Plan to revise rather than treating revision as failure.

Measure your own decision latency. How long between a question being asked and answered? Most clients are surprised, and it is the delay most within your control.

The only reliable lever

Build less.

Everything else on this page is a marginal improvement to how accurately you predict the same amount of work. Cutting a user type, deferring the admin panel or doing onboarding by hand for three months changes the amount of work — and it is available immediately, at no cost, on every project.

A quick reference for the conversation with a supplier

When a supplier hands over an estimate, three questions in sequence get more useful information than any negotiation over the headline number: what does this assume about decision turnaround on our side, which of these weeks are you least confident in, and what would you do differently if we told you the deadline was immovable. The answers reveal whether the number reflects genuine thinking about your specific project or a template applied without much adjustment — and a supplier who visibly pauses to think through the second question, rather than reciting a rehearsed answer, is usually one who has estimated honestly rather than optimistically.

How this connects to cost

Timeline and cost are the same underlying variable expressed two ways — the scope decisions covered in what to build first are simultaneously the biggest lever on both, which is why cutting scope is the only technique on this page that improves timeline without any corresponding trade-off elsewhere. Every other technique here — better estimation, tighter decision latency, honest ranges — makes the same amount of work more predictable. Cutting scope reduces the amount of work itself, which is a different and larger kind of improvement.

If you are working with an external supplier and want the contract structure to reflect this kind of honest, range-based planning rather than a single confident date, fixed price versus time and materials covers how a milestone structure keeps timeline commitments realistic without either side pretending to certainty neither has.

What this looks like from the other side of the table

Suppliers who estimate honestly have their own version of this problem: an accurate range with named risks reads, to an inexperienced buyer, as less confident than a competitor's single optimistic number — even though the range is the more trustworthy answer. Buyers who understand why estimates skew short, and specifically ask for the reasoning behind a number rather than just the number itself, reliably get better answers from good suppliers and flush out the ones padding or guessing. Asking "what would make this wrong" is not an adversarial question — it is the question that lets an honest supplier be honest without sounding evasive.

Estimating in a world where implementation got faster

One further wrinkle worth naming explicitly: as AI tooling compresses the time to write code, the proportion of a project's total timeline spent on non-coding work — specification, review, integration waiting, decision latency — has grown, not shrunk. This means the estimation advice in this piece has become more important, not less, even as the underlying work happens faster. A shorter coding phase inside the same amount of scoping, review and integration overhead produces a project where the ratio of "waiting on decisions" to "waiting on code" has shifted meaningfully, and plans that do not account for that shift will systematically underestimate how much of the calendar those non-coding phases now represent.

A practical next step

If you are about to commission a build, do this before the first conversation with a supplier: write down, in a sentence each, what you already know about your integrations, your compliance obligations, and how quickly decisions get made on your side. Hand that to every supplier you talk to as context before they estimate, rather than letting each one discover it independently through their own questions. It costs you twenty minutes and it removes the single largest source of variance between the quotes you receive back — because at that point every supplier is estimating against the same known information rather than against their own guesses about what you have not yet told them.

Why this matters more than it used to

Timeline accuracy has become a sharper competitive question than it was a few years ago, simply because more capital is now allocated on shorter cycles — a team that can credibly commit to a ten-week delivery and hit it consistently earns trust that compounds across an entire funding relationship, while a team that misses dates repeatedly, even for understandable reasons, erodes that trust regardless of how good the eventual output is. Treating estimation as a discipline worth investing in — rather than an unavoidable guessing game everyone quietly accepts will be wrong — is increasingly a genuine differentiator between suppliers, and between internal teams, not just a nice-to-have.

One more thing worth saying

None of this is a case for pessimism about timelines — it is a case for honesty about them. Teams that plan accurately, including for the unknowns described throughout this piece, ship on schedule far more often than teams that plan optimistically and then scramble. Accuracy, not optimism, is what actually protects a launch date.

The team that plans this way looks different from the outside

An organisation that has internalised this way of thinking about timelines is recognisable from the outside before you ever see a specific estimate. They ask about your decision-making process before quoting a date. They name their own uncertainty rather than hiding it behind a confident number. They treat a milestone slipping as information to act on immediately, not as something to explain away at the end of a quarter. None of that requires exotic project management technique — it requires treating the structural causes of overrun described throughout this piece as the actual subject of planning, rather than as unfortunate exceptions to a plan that assumed none of them would happen.

Closing thought

Timelines are not a mystery to be solved once and for all — they are a discipline to practise on every project, refined by the actual data your own team generates each time. Start tracking, start asking the right questions, and the accuracy compounds.

Last word

If you take one habit from this piece, make it this: track your own actuals against your own estimates, on every project, and let that data — not a generic industry rule of thumb — become your real forecasting tool over time.

Final note

A good estimate is not a prediction of the future. It is a statement of what is currently known, offered honestly, and revised as more becomes known along the way.