MVP — minimum viable product — is one of the most misused phrases in startups. Too many founders read it as "a cheap, half-finished version". It actually means the smallest thing you can build that answers your riskiest question. Get that framing right and the eight-week timeline stops sounding ambitious and starts sounding obvious. Get it wrong and you'll spend six months and a lot of money building features nobody asked for.
First, name the one thing you're not sure about
Every idea rests on an assumption that, if wrong, sinks the whole thing. "People will pay to book cleaners through an app." "Restaurants will keep their menus updated." "Drivers will accept jobs at this price." Your MVP exists to test that sentence — nothing else. Write it down. Everything that doesn't help you learn whether it's true is, for now, a distraction.
Deciding what to leave out. Every feature you cut from version one buys you speed, saves you money, and sharpens the test. You are not building the final product — you're building the fastest honest experiment.
What eight weeks actually looks like
This isn't a rigid formula, but it's close to how a focused MVP tends to run when the scope is honest and the team is senior.
Weeks 1–2: Scope and design
Nail down the core user journey — the single path from "arrives" to "gets value". Sketch the screens, agree exactly what's in and what's explicitly parked for later. Nothing gets built until this is signed off, because changing your mind here costs minutes; changing it in week six costs weeks.
Weeks 3–6: Build
The product comes together in weekly increments you can actually see and click. Using proven foundations — modern frameworks, ready-made authentication and payments, managed hosting — means the budget goes into what makes your idea different, not into rebuilding plumbing every startup needs.
Weeks 7–8: Test, fix, launch
Real devices, real edge cases, real people trying to break it before your users do. Then it goes live — not perfect, but genuinely usable, and in front of the people whose behaviour will tell you whether your big assumption holds.
What belongs in version one (and what doesn't)
| Build now | Wait |
|---|---|
| The one core action users come for | A second user type "for later" |
| Sign-up and basic accounts | Social logins, referral systems |
| Taking payment, if money is the test | Subscriptions, discounts, credits |
| A simple admin view for you | Analytics dashboards, reporting |
| Working on a phone | A separate native app |
If a feature isn't in the "build now" column, the honest question is whether it's earning its place — or just feeling safe. For a fuller sense of how scope maps to budget, our guide to what a web app costs in the UK puts real numbers against these decisions.
The part nobody tells first-time founders
An MVP is not the finish line — it's the starting gun. The point was never the software; it was the learning. Launch day is when you finally get real answers, and those answers should reshape what you build next. Founders who treat the MVP as version one of a living product win. Those who treat it as a smaller version of a fixed plan usually don't.
When the idea's ready but the funding isn't
Here's the situation we see constantly: a founder with a genuinely good idea, the drive to make it real, and not enough cash to write an agency a five-figure cheque up front. That's not a reason to give up or to build something cheap and broken. It's exactly the gap our funded-build model exists to close.
For ideas we believe in, we don't just build the product — we invest in it, up to £50,000, cover the cost of designing and developing the MVP, and back you as a long-term partner rather than a one-off client. You get a senior team and the capital to launch, in exchange for a stake in what you're building together. If capital is the only thing between you and a live product, that's worth exploring before you compromise the idea to fit a budget.
Start with the smallest honest version
Eight weeks is enough to turn an idea into something real, provided you're ruthless about scope and clear about the one question you're trying to answer. Build that, put it in front of real users, and let what you learn fund and shape everything that comes after. The founders who move fastest aren't the ones who build the most — they're the ones who build the right small thing first.