What Is an MVP and Do You Actually Need One?

MVP gets thrown around so often in startup conversations that it's started to lose meaning. Investors say it. Accelerators say it. That one friend who read a Paul Graham essay says it. And yet most first-time founders I talk to are still genuinely unclear on what a minimum viable product actually is, and more importantly, what it isn't.

So let me give you the practical version.

What an MVP Actually Is

An MVP is the smallest thing you can build that lets a real user accomplish the core job your product promises to do. Not a sketch. Not a pitch deck. Not a beta with a waiting list. An actual working thing someone can use.

The "minimum" part doesn't mean low quality. It means ruthlessly scoped. You're not building every feature, you're building the one feature that proves your idea has legs. Everything else comes later, once you've confirmed that the core problem is real and that people will actually pay (or return) to solve it.

Eric Ries, who popularised the term in The Lean Startup, defined it as a vehicle for learning. That framing matters. The point of an MVP is not to launch a product. The point is to test an assumption as cheaply and quickly as possible.

What It Isn't

Here's where most people go wrong: they either build too much or too little, and both mistakes are expensive.

Building too much looks like this. You spend six months and €30,000 getting a full platform built with user accounts, a dashboard, filters, notifications, an onboarding flow, and a mobile-responsive design, before a single person has told you they want the thing. That's not an MVP. That's a product launch with no validation.

Building too little on the other hand: you put up a landing page, collect some email addresses, and call it validated. A landing page tells you whether people are curious. It does not tell you whether they'll use or pay for what you're building. There's a real difference.

A real MVP sits between those two extremes. It's functional enough to deliver actual value, and scoped tightly enough that you could build it in weeks, not months.

Should You Build One, or Validate First?

Before you commission any development work, it's worth asking an honest question: can you validate your assumption without building anything?

For some ideas, the answer is yes. If you're building a service business with a tech layer on top, you might be able to run the first ten clients manually — using spreadsheets, email, and calendar invites — before you automate anything. This is sometimes called a "concierge MVP," and it's a legitimate approach when the manual version is actually feasible.

Then over time, you can convert those spreadsheets into the foundation for your actual application.

But for a lot of software ideas, you can't fake the core experience. If your product is a tool people use to do something, they need to be able to use it. In those cases, you do need to build something and the question becomes how little you can build while still proving the point.

When to Hire vs. DIY

If you're non-technical, you have three realistic options: use a no-code tool, hire a developer, or find a technical co-founder. Each has its place.

No-code tools are genuinely useful for simple MVPs. Large language models like Claude can build more and more features reliably and can actually make decent MVPs. Alternatively, using WebFlow or Bubble, you can make simple CRUD apps or form-heavy applications. If your product concept is straightforward and you're comfortable learning a new platform, it's worth exploring before you spend money on custom development. The trade-offs are real (limited flexibility, harder to scale) but for pure validation purposes, they often don't matter yet.

Hiring a developer makes sense when the core interaction is technically complex, when you have a clear enough idea of what you need, and when you've already done some form of manual validation. The worst time to hire a developer is when you're still figuring out what to build, that's expensive in both time and money.

What I'd flag from experience: the founders who get the most out of MVP development have done the thinking beforehand. They know who the user is, what the one core action is, and what success looks like after six weeks. When that clarity exists, a good developer can move very fast. When it doesn't, you'll spend half your budget in back-and-forth.

How Lean Should It Actually Be?

There's no universal answer, but here's a practical heuristic: if you're embarrassed by how little it does, you're probably in the right zone. If you're proud of how polished it looks, you've probably over-built.

For most B2B tools or internal workflow apps, an MVP should cover one user flow end-to-end, handle the happy path reliably, and not crash. That's genuinely enough to start learning. Authentication, admin panels, email notifications, analytics dashboards, most of that can come later once you know the thing is worth investing in.

The tech stack matters less than people think at this stage. What matters is that whoever builds it can move quickly and doesn't over-engineer it. I default to Ruby on Rails for MVP work because the speed-to-functionality ratio is hard to beat, but the right tool depends on what you're building and who's going to maintain it afterward.

The Question Worth Asking

Before you write a brief, start a no-code project, or talk to a developer, try to answer this in one sentence: what is the single action my user needs to be able to complete, and how will I know if it worked?

If you can answer that clearly, you're ready to build an MVP. If you can't, spend another week on that question first. It'll save you more time than anything else I've mentioned here.

If you're at the stage where you know what you want to build but aren't sure how to scope it or who to build it with, I'm happy to talk it through. Get in touch and we can figure out whether your idea needs a week of no-code, a focused MVP build, or something in between.