How Long Does It Take to Build a Custom Web Platform?

An internal tool that replaces a spreadsheet sits at the short end. A multi-tenant SaaS product sits at the long end. Most things land in the middle.

That much you can read off a price list. What you can't read off a price list is the thing that decides whether you ship in twelve weeks or twenty. And it has very little to do with how fast anyone writes code.

It comes down to decisions, scope and readiness, almost all of which sit on your side of the table.

I build these for a living. The biggest predictor of a late delivery isn't technical difficulty. It's how quickly the client answers a question.

The honest ranges, by what you're building

An internal operations tool is the fastest kind of build. Think a dashboard, a booking system, a member portal replacing spreadsheets and scattered subscriptions. The logic is contained, the users are few and known, and there's rarely a public surface to harden. Roughly eight to ten weeks.

A customer-facing product or MVP takes longer. Once you add accounts, payments and an admin panel behind them, every surface has to survive real users and real money. A checkout that fails under load isn't cosmetic. Ten to fourteen weeks.

A complex platform is the longest. Multi-tenant SaaS, a marketplace, real-time collaboration, subscription billing. The architecture has to be right before the features go on top, and rebuilding the foundations later is the most expensive mistake in this business. Twelve to sixteen weeks.

Two things break the pattern.

Integrations inherit the timeline of whatever they connect to. A modern, well-documented API might take days. A legacy system with poor documentation can take a fortnight or more on its own.

Regulated builds carry review cycles that sit outside development entirely. In healthcare, the NHS Digital Technology Assessment Criteria (DTAC) can run from a few weeks to six months, depending on the product. That clock runs alongside the build, not inside it.

For context: across the UK agencies that publish timelines, MVPs cluster around four to eight weeks, and standard platforms around three to six months. Our ranges sit at the honest end of that. A number you can hit is worth more than one that wins the pitch.

It's also why we quote in fixed bands rather than a single hopeful figure. Two agencies can be four times apart on the same brief without either of them lying.

Why it's a range, not a date

Software runs late as a rule. The Standish Group's original CHAOS research put the average schedule overrun at 222% of estimate (1994, US/global figure, old, but the direction hasn't reversed). A 2012 academic synthesis found that 35% to 80% of projects exceed their planned time, averaging 22% to 25% over (global).

The cause is rarely slow typing. It's that the estimate was made before anyone knew what they were building.

Most of the slippage lives in the gap between an idea-stage guess and a proper plan made after the architecture exists. Closing that gap before the clock starts is the whole point of a Platform Discovery Sprint. It's why we scope and quote every build individually.

What actually slows a build down

Once a build is underway, the schedule gets eaten in a few predictable ways.

Decision latency is the big one. If a question that should take three hours takes three days, everything queued behind it waits too. A fortnight of work can stretch to several weeks. Not because anything was hard, but because the build kept stopping for answers.

Scope change mid-build is next. A feature added after the spec is agreed isn't just its own build time. It's rework in design, testing, documentation and release. Each substantial addition tends to cost a week or two, and a late architectural change can cost months.

We saw this on Student Central. The initial brief carried features that would have added weeks without serving the core idea. We recommended stripping back to the matching engine that mattered and phasing the rest. That discipline is why we lock scope in the fixed-price proposal. It's the thing funded founders get wrong most often.

Unready content and data slows things too. A platform with nothing to migrate from stands up quickly. One that has to ingest years of messy legacy data does not, and the cleaning is almost always underestimated.

Then there's access. Integration can't start until there's something to connect to. API keys, admin permissions, a sandbox account. Each one is a gate, and a gate left shut for a week is a week.

How to speed it up on your end

The levers that matter most are yours, and they cost nothing.

Name one decision-maker. A single person who can say yes beats any methodology. Decision-by-committee is where weeks go to die, with every approval waiting on the slowest calendar in the room.

Agree turnaround times up front. Commit both sides to answering within a working day and the schedule holds. We build weekly check-ins and staging access into every project so feedback happens throughout, not in a rush at the end.

Have your inputs ready before kick-off. Data to migrate, content to load, credentials for anything we connect to. Work done before week one isn't blocking week eight.

Freeze the first version. Agree what v1 has to do, then resist adding to it until it ships. There's always a second version, and the fastest route to live is a small, well-defined first one. Writing that spec well is its own skill: how to brief an agency properly.

When the answer is "longer than you'd like"

One thing worth saying plainly. If you need a platform live in under six weeks, a custom build is the wrong tool, and we'll tell you so. A rushed bespoke project disappoints everyone.

The same goes for budget. Under £20,000, the maths doesn't support proper discovery, design and development. A focused freelancer or a no-code specialist will give you more. We've written about where that line sits.

Above those thresholds, the timeline is knowable. The range is honest. And most of what decides where you land is within your control.