How long does it take to build a custom web application?

“How long will it take” gets answered with a number that sounds confident and turns out to be conditional on about fifteen things nobody listed. Here is what actually determines the answer, and where the time really goes.

Schedule is the thing that slips least

This surprises people. In the McKinsey and University of Oxford analysis of more than 5,400 IT projects, the average schedule overrun was 7%, while the average cost overrun was 45% and the average value shortfall was 56%.

Dates hold because dates are visible. When a project is late, teams add people, work longer, cut testing and drop scope. The date survives and the cost and the quality absorb the difference. So a supplier hitting the date tells you considerably less than it appears to, and “we always deliver on time” is not the reassurance it sounds like.

The useful question is not whether the date will hold. It is what will be sacrificed to hold it.

A realistic shape

For a mid-sized custom web application, meaning real users, several roles, a handful of integrations and a database that matters, the pattern looks like this.

Two things about that shape are worth noticing. Discovery is on the critical path, and skipping it does not remove the work, it moves it into the build where it costs more. And stabilisation is part of the timeline even though it happens after the launch party.

What actually moves the date

How much is undecided. A build with agreed workflows and known edge cases can be estimated within roughly fifteen percent. One described as “like our current system but better” cannot be estimated at all yet. The undecided scope is the delay, not the estimate.

Integrations, and who controls them. A documented API with a sandbox is routine. A system with no test environment, no documentation and a vendor who charges for API access is a different project with the same description. Getting credentials from another company’s security team has taken us longer than building the integration, more than once.

Data condition. Migration is underestimated because people picture a copy operation. The work is deciding what to do about duplicate records, fields used for something other than their label, and required values that are empty in a third of rows.

Decision latency on your side. This is usually the largest and the least discussed. If a question from the team takes eight working days to answer, the team either waits, which you pay for, or assumes, which you pay for later. Reducing the number of people who must approve things shortens projects more reliably than any technical choice.

Approval and review cycles. Security review, legal sign-off, accessibility audit, procurement. All real, all necessary, all needing to be in the plan rather than discovered in week fourteen.

What does not move it as much as people think

Adding developers. Adding people to a late project reliably makes it later, because the existing team loses time explaining context. There is a team size beyond which coordination costs exceed the added capacity, and for most web applications it is smaller than expected.

Technology choice. Framework arguments consume far more time than the frameworks differ by. Established, boring, well-supported tools are rarely the bottleneck.

Working longer hours. Buys a couple of weeks, then costs them back in defects. The McKinsey figures are consistent with this: schedules hold and quality absorbs the difference.

How to get a date you can plan against

A single date with no stated assumptions is a forecast dressed as a commitment. What you want instead is a range, the assumptions it depends on, and an agreed mechanism for what happens when one of them turns out wrong.

We quote in two stages for that reason. A short fixed-price discovery establishes scope, maps every integration, looks at the real data and settles the architecture, then produces an estimate with a stated range and written assumptions. Only then do we price and schedule the build. Work runs in two to three week releases, so if something moves you find out in a fortnight rather than a quarter.

That cadence matters more than the initial estimate. The worst overruns in the McKinsey data clustered in projects with infrequent checkpoints, where a quarterly review meant three months could pass before anyone noticed the project had drifted.

There is more on where the budget goes in what custom software actually costs, and on keeping a first release small enough to finish in deciding what to build first.

If you have a deadline you need to hit, tell us the date and what it is tied to. Whether it is achievable is usually a scope question rather than a speed question.