A lean web MVP with one core workflow, sign-up and Stripe payments launches in 8 to 12 weeks: a week of discovery, two of design, six of build in two week sprints and a soft launch. Two-sided marketplaces, or an MVP with a mobile app, usually take 12 to 18 weeks. A clickable prototype for investor meetings or user testing takes two to three weeks, and the code and IP belong to your company from day one.
An MVP is an experiment, not a small version 1
The point of a minimum viable product is to find out, with real users and real commitment, whether the thing you believe is true. Will accountants upload their clients' receipts to a new tool? Will gym owners switch to automated class waitlists? Will a hauliers' network share spare capacity with competitors? An MVP answers one question like that as quickly as possible.
That changes how you build it. A version 1 tries to be complete. An MVP tries to be convincing on the one thing that matters and deliberately rough everywhere else. The sign-up flow works, the core feature works well, payment works, and almost everything else is manual, missing or held together with a spreadsheet behind the scenes.
Founders who treat the MVP as a small version 1 spend twice as long, launch with features nobody tested, and still do not know the answer to the original question.
Test it without us first
Before you commit to building software, it is worth asking whether a week with simple tools could answer the same question. Often it can.
- A landing page and a waitlist. Describe the product and see who signs up. Point a small LinkedIn or Google ads campaign at it if your audience is easy to target.
- A concierge test. Deliver the service by hand to five customers, using email, a Typeform and a spreadsheet. If people will not commit to the manual version, software will not save it.
- No-code tools. Airtable, Softr, Bubble or Glide with Stripe Payment Links can run a surprisingly convincing product for the first 20 customers.
- Letters of intent. For B2B ideas, three signed letters or paid pilots from target customers are worth more than any prototype.
Come to us when the manual or no-code version is creaking because people are using it, when the core of your idea is technically hard (complex matching, scheduling, calculations, data processing or AI), or when investors or enterprise customers need to see something production grade.
How we cut an MVP down to ten weeks
Scope cutting is the most valuable thing we do in discovery, and most first briefs we see could lose half their features without weakening the experiment. Our method is blunt.
- Write the one sentence. "A [customer] can [do the core job] and will [commit in a specific way]." Every feature is tested against that sentence.
- Fake everything you can. Onboarding can be a call with you. Billing can run from the Stripe dashboard. Admin can be a database tool rather than a custom console. Reports can be a CSV export.
- Pick one platform. Usually a responsive web app. A mobile app doubles testing and adds store approval to every release.
- One user type if possible. Marketplaces need two sides, which is why they take longer. If you can seed one side by hand, do.
- Write down what you are not building. The "later" list is part of the specification, so nobody is surprised.
A founder who arrives with 40 features usually leaves discovery with 8 to 12. The others are not lost. They become the roadmap for after the first customers have told you which ones they actually want. Our discovery and specification page explains what you get from that phase.
The ten week MVP timetable
- Week 1: discovery. Two workshops, the one sentence, the feature cut and a data model. If we cannot see a viable scope for the time you have, we tell you here, before anything is built.
- Weeks 2 to 3: design. Clickable prototype of the sign-up, the core feature and payment. You put it in front of five target customers before we write production code. Changes here take hours, not weeks.
- Weeks 3 to 8: three build sprints. Sprint one: accounts, data model and the skeleton of the core feature. Sprint two: the core feature properly, including the edge cases that make it trustworthy. Sprint three: payments, emails, admin and analytics. Each sprint ends with a demo on a test link you can share with advisers.
- Week 9: testing and soft launch. Real users on the live system, invited in small batches, with us watching error logs daily.
- Week 10: public launch. Then a 30 day warranty for anything that does not match the specification.
Your part is roughly a day a week: decisions, user interviews and feedback on each demo. MVPs stall when the founder is unavailable, not when the developers are. For the wider process, see how we work.
Clickable prototypes for investors and user tests
Some founders are not ready to build yet. They need something to put in front of investors, a design partner or twenty potential customers. For that we produce a clickable prototype in two to three weeks.
It looks and behaves like the real product on a laptop or phone: you can sign up, tap through the core journey and see realistic screens filled with believable data. Underneath there is no database and no code, which is exactly why it can change in an afternoon after each round of feedback.
A good prototype answers two questions an investor will ask: do you understand the user's problem in detail, and can you explain the product in five minutes? It also gives you something concrete for user interviews, which produce far better feedback than a description ever does. When you are ready to build, the prototype becomes the design brief for the MVP, so none of the work is wasted.
Measuring whether the experiment worked
An MVP without measurement is a product launch with extra steps. Before launch we agree, in writing, what success looks like and what number would make you change course. Typical measures for a B2B product:
- Activation: the share of sign-ups who complete the core job within their first week.
- Retention: how many active accounts are still active after four and eight weeks.
- Conversion: how many trials become paying customers, and how long it takes.
- Qualitative signal: what the first twenty users say in a short call, recorded and tagged.
We wire these events into product analytics with EU data hosting, add a simple dashboard to the admin console, and set up session recording on key screens where the privacy notice allows it. After a month you have numbers, not impressions, and the next decision is easier to make.
Built to survive investor due diligence
If the MVP works, you will probably raise money, hire a CTO or both. Each of those involves someone senior looking hard at your code and your contracts. We build for that moment from the first week.
- Clean ownership. Copyright and IP in everything we write are assigned to your company. Investors check this, and an MVP built by a friend on a handshake is a common reason rounds stall.
- Your accounts. GitHub, cloud hosting, Stripe, domain and email are all in the company's name from day one. We are users who can be removed.
- Mainstream stack. TypeScript, React or Next.js, Node.js and PostgreSQL. A future CTO can hire for it in any UK city, and nothing depends on an agency framework.
- Readable code. Automated tests on the core logic, a README, and short notes on the decisions we made and the shortcuts we took deliberately.
That last point matters. An MVP carries some technical debt on purpose. Writing it down means your next developer knows which corners were cut and why, instead of finding out in production. If the product grows into a subscription business, our SaaS development work picks up from the same codebase.
Hosting and personal data from day one
Your first users' data is still personal data under UK GDPR, and enterprise customers will ask about it in their first procurement call. We host MVPs in UK or EU regions, typically AWS London or a managed PostgreSQL service such as Supabase in its London region, with backups, encryption and access limited to the people who need it.
We also set up the basics most MVPs skip: a privacy notice that matches what the product really collects, cookie consent if you use analytics, a data processing agreement with us, and a list of the services that touch user data. It takes a day or two and saves a scramble later. More on our security and UK GDPR page.
The first 90 days after launch
Launch day is the start of the experiment, not the end of the project. The first customers reveal what really matters, and the weeks after launch are when the product changes most.
After a month, we sit down with the numbers and the feedback and plan the next two or three sprints. Some founders keep us on a monthly support and development plan, some hire their first developer and use us for handover, and some stop because the experiment gave a clear no. All three are good outcomes, because each one is a decision made on evidence.