The Short Answer
A minimum viable product that does one job end to end takes a small UK team about four weeks to build; one with two or three connected features takes six to eight; a marketplace or anything with payments, compliance and a mobile app alongside the web takes eight to twelve. Those are build weeks, and they are the part of the timeline that a competent developer controls.
The part that catches founders is everything around the build. Apple and Google each hold a clock you cannot speed up. If your product touches regulated financial activity, the Financial Conduct Authority holds a much longer one. If it processes personal data in a way that is genuinely high-risk, the Information Commissioner's Office may hold another. None of those appear in a developer's estimate, because none of them are the developer's to give, and a founder who plans a launch date from the build estimate alone finds out about them at the worst possible moment.
This guide separates the two. First the clocks you control and what moves them, then the clocks you do not, each with the number from the body that runs it. If you are choosing between building and using no-code tools first, our guide to [no-code tools for an MVP](The Best No-Code Tools for an MVP, and When to Write Code Instead) covers that decision; if you are deciding whether it needs to be an app at all, start with [native, cross-platform or web](Native, Cross-Platform or Web App? What UK Businesses Should Decide Before Commissioning).
What Decides the Build Weeks
| Lean MVP | Standard MVP | Complex MVP | |
|---|---|---|---|
| What it is | One core job done end to end, a landing page, sign-up, and analytics | Two or three connected features, an admin view, and a post-launch iteration sprint | A marketplace or multi-sided product with integrations, compliance, and mobile alongside web |
| Who it suits | A founder testing whether anyone wants this at all | A validated idea that needs a few features to be usable | A product where the first version has to satisfy two kinds of user, or a regulator, at once |
| Typical build | Around four weeks | Six to eight weeks | Eight to twelve weeks |
| What most often extends it | The founder changing the one job mid-build | Integrations with systems that turn out to permit less than their documentation implies | Compliance review, payment provider onboarding, and app store clocks that start only when the build ends |
| What you own at the end | Repository, hosting and analytics accounts in your name | The same, plus the admin tooling and the iteration backlog | The same, plus app store accounts, the compliance file and the data processing records |
Three things move a build between those columns more than any feature does.
How many decisions are still open when the build starts. A four-week MVP is four weeks because the one job it does was decided before week one. Every question answered during the build costs the time to answer it plus the time to rework what was built while it was open. The founders who hit their dates are the ones who spent a week before the build writing down what the product will not do.
How many systems it has to talk to. Payments, identity, a CRM, an accounting package, a courier: each one is an integration, and each integration's timeline is set by what the other system permits, not by how quickly a developer can write to it. A documented API with sandbox access is days. A system where the vendor has to approve your connection, or where writing data is allowed but reading it is not, can be weeks of waiting rather than building. We check each one before quoting, and so should any supplier you speak to.
Whether anything in it is regulated. This is the one that turns weeks into months, and it deserves its own section.
The Clocks Nobody Can Shorten
These do not run in parallel with the build by default. Most of them start only when something is finished, which is why they surprise people.
Apple's App Review. Apple's own App Review page states that, on average, ninety per cent of submissions are reviewed in less than twenty-four hours. That is the good news. The part that costs time is rejection: Apple says over forty per cent of unresolved issues relate to guideline 2.1, App Completeness, meaning crashes, placeholder content and incomplete information. A rejection restarts the clock, and the fix has to go back through the same queue. An MVP that ships with a placeholder screen because the founder wanted to test something else first is exactly what that guideline catches. Expedited review exists, but Apple limits it to critical bug fixes and event-related apps, so a launch date is not a reason it accepts.
Google Play's testing requirement. For personal developer accounts created after 13 November 2023, Google Play requires a closed test with at least twelve testers opted in continuously for fourteen days before production access is granted, a threshold Google reduced from twenty on 11 December 2024. That is a minimum of two weeks after the build is finished, before anyone outside your test group can install it, and it only applies to new personal accounts. An organisation account is exempt, which is one of several reasons we set up the developer accounts in the company's name rather than a founder's, on top of the ownership question our [app cost guide](What Decides What It Costs to Build an App in the UK? A 2026 Guide) covers.
The FCA, if your product is a regulated activity. If the MVP lends, holds client money, arranges payments, offers investments or advises on them, it may need FCA authorisation before it can trade at all. Under the Financial Services and Markets Act the FCA has six months to determine a complete application and twelve months for an incomplete one, and the FCA has announced that it is targeting four months and ten months respectively for new firm authorisations, measured from January 2026. Two things matter more than those numbers. The clock starts when the FCA judges the application complete, not when it is submitted, and the "incomplete" track is where thin business plans end up. A founder who discovers this after the build has finished has a working product and no permission to run it. Whether your idea is a regulated activity is a question for a regulatory adviser before anyone writes a line of code, and it is the first thing we ask when a brief mentions money moving between users.
The ICO, if the data processing is genuinely high-risk. UK GDPR requires a data protection impact assessment before processing that is likely to result in a high risk to individuals. In most MVPs the DPIA is a document you complete and keep, and it costs a few days of honest thinking. But where the assessment identifies a high risk that cannot be reduced, the ICO must be consulted before processing starts, and the ICO states it will respond within eight weeks, extendable by a further six in complex cases. That applies to a narrow set of products, typically those profiling people at scale, processing special category data, or tracking location or behaviour in ways users would not expect. If yours is one of them, that consultation belongs in the plan from the start, not after launch.
Payment provider onboarding. Stripe, GoCardless, Adyen and the others verify the business before live payments are enabled, and the verification asks for company documents, director identity and, for some business types, a longer review. It is usually quick for a UK limited company with clean records and can be slow for a sole trader in a category the provider treats as higher risk. The build can proceed on the provider's test mode throughout; the point is to start the live application in week one rather than week eight.
How to Read a Supplier's Estimate
An estimate that says "six weeks" is answering one question: how long the build takes once everything needed for it exists. Ask four more.
What has to be true before week one starts? A good answer names the decisions, the access and the accounts they need from you. A vague answer means the first fortnight will be spent finding out.
Which integrations have you checked, and which are you assuming? The difference between those two words is where most overruns live.
Which external clocks apply to this product, and when do they start? A supplier who has shipped to both stores will name Apple's review and Google's testing period unprompted. One who works in a regulated sector will ask about authorisation before you mention it.
What happens to the timeline when we change our minds? Because you will, and the honest answer is that it depends on when. A change in week one costs a conversation; the same change in week five costs the rework. We quote a fixed price against a written scope for exactly this reason, and re-quote before doing the work when the scope moves rather than after.
What We Need From You to Hit the Date
Most delays in an MVP build are not engineering. They are a decision that stayed open, an account nobody set up, or a person who was unavailable the week their answer was needed. The list is short.
A named decision-maker who can answer a question the same day. The one job the product does, written down, and the list of things it will not do in the first version. Company details ready for the developer, hosting and payment accounts, all of which are created in your name from the start. Access to any system the product has to read from or write to, with whoever owns it available for a short conversation. And two or three people, ideally real prospective users, prepared to try to break it in the final week.
Everything else is ours. If you want to see how the weeks are structured for a booking-led product, the [ecommerce and retail page](AI for E-commerce & Retail) shows how a marketplace build is sequenced around the payment and store clocks; the [MVP development page](MVP Development) sets out the three scopes above in full.
Next Step
If you have a date in mind, the useful conversation is not "can you build it by then" but "which of these clocks apply to it". That takes about half an hour, it is free, and it regularly ends with us telling a founder that a no-code first version would test the idea faster than a build. [Book a discovery call](our contact page), or message us on WhatsApp if you would rather ask one question first.
Frequently Asked Questions
Can we launch faster if we skip the app stores and go web-only?
Often, yes, and it is the first thing worth considering. A web application people can save to their home screen removes Apple’s review, Google’s testing period and the developer account set-up from the timeline entirely, and it is the route we suggest for most first versions. The exceptions are products that need deep device access, push notifications on iOS at a level the web does not yet match, or presence in the stores as part of the pitch. Our guide to native, cross-platform and web apps covers that decision in detail.
Why do agencies quote such different timelines for what sounds like the same MVP?
Because they are answering different questions. One is quoting build weeks from a finished specification; another is including discovery, the decisions still open, and the wait on integrations and store review; a third is quoting the shortest number that wins the work. Ask each one what has to be true before week one starts and which external clocks they have included. The quotes usually converge once they are describing the same thing.
How long does it take if our product handles payments between users?
Longer than the build, and possibly much longer. Taking a payment for your own goods or services is ordinary and the provider’s onboarding is the only clock. Holding or moving money between other people can be a regulated activity, in which case the FCA’s determination period applies before you can trade: six months for a complete application under the statutory deadline, with the FCA targeting four months from January 2026, and longer for an incomplete one. Whether yours crosses that line is a question for a regulatory adviser before the build starts, not after it ends.
What is the single most common reason an MVP build overruns?
A decision that was still open when the build began. Feature creep gets the blame, but in our experience the cause is usually one question about what the product does that nobody answered before week one, and every week it stays open costs the time to answer it plus the rework of whatever was built around the gap. A week spent before the build writing down what the first version will not do saves more time than any technical choice.
Do we need a data protection impact assessment for an MVP?
You need one before any processing likely to result in a high risk to individuals, which the ICO’s guidance defines with a list of indicators such as profiling, special category data, tracking, and processing at scale. For most MVPs it is a document you complete honestly and keep, and it takes days rather than weeks. Only where a high risk remains after mitigation does prior consultation with the ICO apply, with its eight-week response window. We raise it in week one so that, if it applies, it runs alongside the build rather than after it.