Most UK software projects take between 3 and 9 months from kick-off to launch. A lean B2B SaaS MVP runs 12 to 20 weeks, an internal business tool 8 to 14 weeks, and a consumer mobile app with backend, admin panel and API 16 to 28 weeks. Enterprise platforms with deep integrations stretch to 12 to 24 months. The single biggest variables are team dedication and scope: a part-time team adds 60 to 80 per cent to the timeline, while a tight, well-scoped feature set cuts it. A 2 to 4 week discovery phase costing £5,000 to £12,000 typically shortens the overall build and reduces rework by removing guesswork. Rushing has the opposite effect, inflating cost by 25 to 50 per cent. The honest answer: a realistic timeline depends on what you are building, who builds it and how clearly the requirements are defined before a single line of code is written.
Last updated: June 2026
Timelines vary enormously by project type, so the most useful answer is a range tied to what you are actually building. A simple internal automation tool can ship in 8 to 12 weeks. A polished consumer product with a mobile app, a server backend and an admin dashboard is closer to half a year. Below is the comparison table we wish more agencies published up front, pairing realistic UK week ranges with the budget bands that go with them.
| Project type | Typical timeline | UK budget band | Team size |
|---|---|---|---|
| Small automation tool or internal utility | 8 to 12 weeks | £15,000 to £40,000 | 1 to 2 developers |
| Internal business application (line-of-business) | 8 to 14 weeks | £35,000 to £80,000 | 2 to 3 people |
| B2B SaaS MVP | 12 to 20 weeks | £25,000 to £80,000 | 3 to 4 people |
| Consumer mobile app (iOS, Android, backend, admin) | 16 to 28 weeks | £50,000 to £150,000 | 4 to 5 people |
| Full SaaS platform (post-MVP, billing, roles, reporting) | 6 to 12 months | £60,000 to £150,000 | 4 to 6 people |
| Enterprise platform with deep integrations | 12 to 24 months | £150,000 to £500,000+ | 6 to 12+ people |
The pattern is straightforward: complexity, surface area and integration depth drive everything. An MVP is fast because its entire purpose is to validate one core hypothesis with the smallest believable product. A full platform is slow because every feature multiplies the testing matrix, the edge cases and the support burden. Our view, after a dozen years of this, is that the worst outcome is building a "platform" when you needed an MVP. Teams routinely spend nine months and £120,000 building features nobody uses because they skipped the validation step that an MVP exists to provide.
Be sceptical of any quote that gives a single fixed number with no range and no caveats. A reputable UK agency will give you a band, name the assumptions behind it, and tell you which decisions could move the deadline. If your supplier promises a complex platform in "six weeks" with no discovery, that is a red flag, not a bargain. The right comparison is not which agency quotes the shortest timeline, but which one has scoped your project honestly enough that the timeline will survive contact with reality.
Every software project moves through five core phases, and each consumes a fairly predictable slice of the calendar. Understanding the split helps you spot when a project is drifting. As a rule of thumb across UK SME projects, discovery takes 10 to 15 per cent of the timeline, design 15 to 20 per cent, build 40 to 50 per cent, testing and UAT 15 to 20 per cent, and deployment plus stabilisation the final 5 to 10 per cent.
| Phase | What happens | Share of timeline | Typical duration (3-month project) |
|---|---|---|---|
| Discovery and requirements | Scope, user stories, technical approach, success metrics | 10 to 15% | 2 to 3 weeks |
| Design (UX and UI) | Wireframes, prototypes, design system, user flows | 15 to 20% | 2 to 3 weeks |
| Build (engineering) | Front end, back end, database, integrations, APIs | 40 to 50% | 6 to 7 weeks |
| Testing and UAT | QA, bug fixing, security review, user acceptance testing | 15 to 20% | 2 to 3 weeks |
| Deployment and stabilisation | Release, monitoring, early-life support, handover | 5 to 10% | 1 to 2 weeks |
Build is the longest phase but rarely the one that derails a project. The phases that quietly destroy timelines are the ones teams undervalue: discovery and testing. Skimp on discovery and you pay for it threefold in change requests during the build. Skimp on testing and you ship bugs that cost ten times more to fix in production than they would have cost to catch in UAT. The most common mistake we see is a client pushing to "start coding sooner" by collapsing discovery, then watching the build phase balloon because the requirements were never nailed down.
The phases also overlap more than a textbook implies. In a modern delivery, design runs slightly ahead of engineering, and testing happens continuously rather than as a single block at the end. This is why a well-run agile project can feel faster than its phase breakdown suggests: work is parallelised, not strictly sequential. The numbers above describe how effort distributes, not a rigid baton-pass. If your supplier treats each phase as a hard gate where nothing else moves, expect the calendar version to run longer than the effort version.
The factors that stretch timelines are predictable, which means most overruns are foreseeable rather than bad luck. The two heaviest hitters are team dedication and integration complexity. A part-time team, whether yours or the agency's, typically extends a project by 60 to 80 per cent because of context-switching and the constant cost of re-loading the problem each session. Integrations with third-party or legacy systems add weeks because you are at the mercy of someone else's API, documentation and uptime.
Here is the honest rule we give every client: the timeline you are quoted assumes near-perfect conditions, and conditions are never perfect. The realistic delivery date sits between the quoted optimistic figure and a version padded by roughly 20 to 30 per cent for the friction above. Anyone who tells you their estimate has zero risk attached has either not built much software or is not being straight with you.
Data migration deserves a special warning because it is the factor clients dismiss most often and regret most often. "We will just move the spreadsheet across" rarely survives contact with the actual data, which is full of duplicates, missing fields, inconsistent formats and historical decisions nobody remembers. If your project involves migrating any meaningful volume of existing records, budget 4 to 8 weeks for it and treat that figure as a floor, not a ceiling. Pairing a clean migration with a fresh build is also the ideal moment to fix structural problems, which is why a thoughtful business process automation review at this stage often pays for itself.
For most UK business software, agile delivers usable value faster, while waterfall can finish a fully-specified project on a more predictable date. They optimise for different things, so "faster" depends on what you mean. Agile gets a working slice of the product in front of users in weeks and improves it iteratively. Waterfall plans everything up front, then builds it in one sequence, which suits fixed-scope projects with hard regulatory constraints but punishes any mid-project change.
| Dimension | Agile | Waterfall |
|---|---|---|
| Time to first usable version | Fast (weeks) | Slow (full build first) |
| Handles changing requirements | Excellent | Poor and expensive |
| Date predictability for fixed scope | Moderate | High |
| Best for | MVPs, evolving products, SaaS | Fixed-scope, heavily regulated builds |
| Risk of building the wrong thing | Low (constant feedback) | High (feedback only at the end) |
| Total time-to-market for a new product | Lower | Higher |
Our stance is unambiguous for new digital products: run agile with two-week sprints, ship a thin vertical slice early, and let real usage steer the roadmap. The biggest cost in software is not coding the wrong feature quickly, it is coding the wrong feature thoroughly. Waterfall front-loads all the planning and only reveals whether the plan was right at the very end, by which point correcting course is enormously expensive. Agile reveals the same truth in week three for the cost of a single sprint.
That said, agile is not a licence for endless scope. Without discipline, "iterative" becomes a euphemism for "never finished". The fast agile teams pair sprint flexibility with a fixed, well-defined MVP boundary: the iteration happens within an agreed scope, not as an excuse to keep adding. The teams that drift are the ones that treat agile as permission to avoid deciding what they are building. If you want both speed and a date, the answer is agile delivery inside a firmly bounded MVP definition, which is exactly the model we use for bespoke software development engagements.
A discovery phase saves time because it replaces expensive mid-build guesswork with cheap up-front decisions. A focused 2 to 4 week discovery, costing £5,000 to £12,000 for a typical UK SME project, can cut total project cost by up to 30 per cent and remove most of the rework that bloats the build phase. The maths is simple: a wrong assumption caught in a discovery workshop costs an afternoon, while the same wrong assumption caught in week ten of the build costs a fortnight of rebuilding.
Discovery produces a small number of high-value artefacts that everything downstream depends on:
The counterintuitive truth is that spending two to four weeks not building software is the single most reliable way to finish sooner. Teams that skip discovery to "save time" almost always lose more time later, because the build becomes a series of expensive course-corrections. We have inherited rescue projects where the entire overrun traced back to a discovery phase that was cut to save £8,000, then cost £40,000 in rework. The honest rule: if a supplier is willing to skip discovery to win your business, they are quietly transferring that risk onto your budget.
Discovery also fixes the relationship, not just the plan. It is the phase where you find out whether you and your supplier communicate well, share assumptions, and agree on what "done" means. A good discovery output reads like a contract you would be comfortable being held to. If, after discovery, the scope still feels fuzzy and the estimate still feels like a guess, that is valuable information: it tells you to tighten the requirements before committing the full build budget, not after.
Cost and timeline are linked but not in the simple way most people assume: paying more does not always buy speed, and rushing almost always inflates cost. UK software cost is driven primarily by the number of developer-days a project consumes, and day rates set the price of each of those days. Blended UK agency rates sit around £525 to £700 per day, with London commanding £500 to £900 and regional teams £400 to £700.
| Resource | London day rate | Regional UK day rate |
|---|---|---|
| Junior developer | £400 to £550 | £300 to £450 |
| Mid-level developer | £550 to £700 | £450 to £600 |
| Senior developer | £700 to £900 | £550 to £750 |
| Blended agency rate | £525 to £700 | £400 to £700 |
The relationship people get wrong is the "crash the schedule" instinct. Adding bodies to a late project rarely makes it faster and often makes it slower, because new people need onboarding and coordination overhead grows with team size. Rushing a project, by compressing testing or skipping discovery, typically inflates total cost by 25 to 50 per cent through rework, bugs and technical debt. You pay the rushed time back later, with interest, in maintenance.
The smarter lever is scope, not speed. If you need to hit a date, cut features rather than corners. A tightly-scoped MVP delivered on time and built well is far cheaper over its life than a bloated product rushed to a deadline and patched for two years afterwards. Our honest advice to UK founders: fix your budget and your launch date, then let scope be the variable. Treating scope as fixed and trying to compress time is how projects end up 50 per cent over budget. The same principle applies whether you are commissioning a custom CRM, a mobile app or an internal platform.
Software projects slip for boringly consistent reasons, and the data confirms it is the norm rather than the exception. Research by McKinsey found that 45 per cent of large software projects run over budget, and 7 per cent are delivered more than a year late. The causes are rarely exotic. They cluster around unclear scope, slow decisions, underestimated integrations and part-time attention, all of which are preventable with discipline.
| Cause of slippage | Typical impact | How to prevent it |
|---|---|---|
| Scope creep | Weeks per major addition | Fixed MVP boundary, formal change control |
| Slow client feedback | 1 week lost per stalled approval | Named decision-maker, 48-hour feedback SLA |
| Underestimated integrations | ~6 weeks per tricky API | Validate APIs during discovery, not build |
| Part-time team | 60 to 80% longer | Dedicated squad, protected sprint capacity |
| Data migration surprises | 4 to 8 weeks | Audit and clean data early as a workstream |
| Weak testing | Costly production bugs | Continuous QA, real UAT before launch |
The honest stance: most overruns are management failures, not engineering failures. The code is rarely the bottleneck. The bottleneck is a decision that took three weeks to make, a requirement that changed in week eight, or an integration nobody validated until the build was already half done. Prevention is not glamorous. It is naming a single empowered decision-maker, agreeing a fast feedback turnaround, freezing the MVP scope and writing every change request down so its cost is visible before it is approved.
The other prevention lever is choosing a delivery model that surfaces problems early. Agile sprints with regular demos make slippage visible within weeks, when it is cheap to correct, rather than at a single final reveal when it is catastrophic. If your project only shows you a working product at the very end, you have no early warning system. Demand to see something real every two weeks. A supplier confident in their delivery will welcome that visibility; one that resists it is often hiding a schedule that is already drifting.
To make the ranges concrete, here is a realistic week-by-week timeline for a representative project: a B2B SaaS MVP for a UK services business, with user accounts, a core workflow, a payment integration and an admin dashboard. This is a 16-week build at roughly £55,000, and it shows how the phases interlock in practice rather than in theory.
| Weeks | Phase | What gets done |
|---|---|---|
| 1 to 3 | Discovery | Workshops, MVP scope lock, user stories, architecture, estimate, risk register |
| 3 to 5 | Design | Wireframes, clickable prototype, design system, user-flow sign-off |
| 5 to 12 | Build (4 sprints) | Auth, core workflow, payment integration, admin dashboard, API |
| 11 to 14 | Testing and UAT | QA throughout, security review, client acceptance testing, bug fixing |
| 14 to 16 | Launch | Deployment, monitoring, early-life support, handover and training |
Notice the overlaps. Design starts in week three while discovery is finishing, and testing begins in week eleven while the final build sprint is still running. That parallelism is what keeps a 16-week project to 16 weeks. If every phase waited for the previous one to fully complete before starting, the same scope would run closer to 22 weeks. Sequential delivery is slow delivery.
Now watch what happens when the common risks bite. If the payment integration turns out to be poorly documented, add around 6 weeks. If the client takes a week to approve each design milestone instead of 48 hours, add 3 to 4 weeks of pure waiting. If the team is shared across other projects rather than dedicated, the whole thing stretches by 60 to 80 per cent, turning a four-month project into a seven-month one. None of these are exotic. They are the ordinary frictions that turn a tidy estimate into a slipped deadline, which is precisely why the discovery risk register exists to flag them before they happen. This worked example is broadly the shape of a typical web application development engagement.
Softomate runs every build through a fixed five-stage process designed to protect your timeline and price, with a fixed quote agreed before the build begins so there are no surprise invoices. We are a London-based software and automation agency in Stanmore (HA7), and the model below is what we use across bespoke software, mobile apps, AI tooling and process automation. The principle is simple: we de-risk the timeline in discovery so the rest of the project runs to plan.
| Stage | Duration | You receive |
|---|---|---|
| Discovery and scoping | 2 to 3 weeks | Fixed quote, scope document, architecture, risk register |
| Design and prototyping | 2 to 3 weeks | Wireframes and a clickable prototype |
| Agile build | 6 to 14 weeks | Working software, demo every two weeks |
| Testing and UAT | 2 to 3 weeks | Tested, secure, accepted product |
| Launch and support | 1 to 2 weeks plus ongoing | Live product, training, support window |
Our discovery phase starts from £5,000 and bespoke software builds typically start from £25,000 for a focused MVP, with most UK SME platforms landing in the £35,000 to £80,000 range. We quote a fixed price against an agreed scope so you are not exposed to open-ended day-rate billing, and any change request is priced and approved before it touches the timeline. If you want to compress a build, we will tell you honestly which features to cut rather than which corners to skip. Whether the project is a custom platform, an AI automation system or a mobile app, the process and the candour are the same.
A realistic UK MVP takes 12 to 20 weeks for a B2B SaaS product and 8 to 14 weeks for a simpler internal tool. The exact figure depends on the number of core features, any integrations and whether the team is dedicated. Budget £25,000 to £80,000 for a typical MVP build.
The fastest genuinely useful MVP we would commit to is around 8 weeks, and only for a tightly-scoped internal tool with no complex integrations and a dedicated team. Anything promising a complex product in a handful of weeks is either skipping discovery and testing or quietly redefining what "finished" means.
Only up to a point. Adding people to a late project usually slows it down because of onboarding and coordination overhead. The reliable way to go faster is to reduce scope, not to spend more. Rushing typically inflates total cost by 25 to 50 per cent through rework and bugs.
A consumer mobile app with iOS, Android, a backend and an admin panel typically takes 16 to 28 weeks. A simpler single-platform app with limited features can land in 10 to 16 weeks. Cross-platform frameworks can shorten the build versus two fully native apps.
Discovery replaces expensive mid-build guesswork with cheap up-front decisions. A 2 to 4 week discovery costing £5,000 to £12,000 can cut total project cost by up to 30 per cent by removing rework. A wrong assumption caught in a workshop costs an afternoon; caught in the build it costs a fortnight.
Data migration commonly adds 4 to 8 weeks and is the factor clients underestimate most. Existing data is usually full of duplicates, missing fields and inconsistent formats that must be cleaned before migrating. Treat that 4 to 8 week range as a floor, especially for older systems with years of accumulated records.
For most new digital products, agile gets usable software in front of users faster and handles change far better. Waterfall offers more predictable dates for fixed-scope, heavily regulated builds but punishes any mid-project change. For SaaS and MVPs, agile inside a firmly bounded scope is the faster route.
Blended UK agency rates sit around £525 to £700 per day. London developers range from £500 to £900 per day depending on seniority, while regional UK teams run £400 to £700. Senior London engineers can reach £900 per day, juniors start nearer £400.
McKinsey research found 45 per cent of large software projects run over budget and 7 per cent are delivered more than a year late. The usual causes are scope creep, slow client decisions, underestimated integrations and part-time teams, all of which are preventable with a fixed scope, fast feedback and a dedicated squad.
The two biggest accelerants of delay are a part-time team, which adds 60 to 80 per cent to the timeline, and unvalidated integrations, where a single tricky API can add around 6 weeks. Slow client feedback and scope creep follow close behind. Most overruns are management issues, not coding ones.
A realistic UK software timeline runs 3 to 9 months for most SME projects: 8 to 14 weeks for an internal tool, 12 to 20 weeks for a B2B SaaS MVP, 16 to 28 weeks for a consumer mobile app, and 12 to 24 months for an enterprise platform. The numbers move on a few predictable levers. A part-time team adds 60 to 80 per cent, tricky integrations add around 6 weeks each, and data migration adds 4 to 8 weeks. A 2 to 4 week discovery costing £5,000 to £12,000 cuts total cost by up to 30 per cent, while rushing inflates it by 25 to 50 per cent. With 45 per cent of large projects running over budget, the projects that hit their dates are the ones that lock scope early, decide fast and stay dedicated. Get those three right and the timeline stops being a gamble and becomes a plan you can stand behind.
If you want a fixed-price, honestly-scoped timeline for your project, talk to our team about bespoke software development in London and we will give you a realistic date, not an optimistic one.
Written by Deen Dayal Yadav, Founder of Softomate Solutions, a London-based software development and AI automation agency in Stanmore (HA7). With over 12 years building software and automation systems for UK businesses, from B2B SaaS platforms to bespoke internal tools and mobile apps, he has scoped and delivered projects across the timeline spectrum and seen exactly where they slip. Softomate Solutions is registered at Companies House and works with founders and operations leaders across London and the UK to ship software on time and on budget. Learn more about Softomate Solutions or get in touch for a scoping conversation.
We protect the real names of all clients featured in examples and case studies. Every testimonial is from a real client.
More from the blog
Work with us
Every project we take on has a measurable outcome. Talk to our London team and we will show you exactly how we would approach your challenge.
Softomate Solutions Limited
Deen Dayal Yadav
Online
