A minimum viable product is the smallest thing you can build that produces real information about whether people want what you're selling. Not a cheap version of your product. Not "phase one." An experiment, with a question attached and a result you'll actually act on.

That distinction sounds academic until you're spending money. It's the difference between a $20,000 build that tells you something and a $20,000 build that tells you nothing. This is one part of the founder's guide to building an MVP.

The definition, and why the usual one misleads

The standard definition — "a version of a product with just enough features to be usable by early customers who can then provide feedback" — is accurate and quietly misleading. Founders read "just enough features to be usable" and think about their product working. The emphasis belongs on feedback.

A more useful phrasing: an MVP is the cheapest experiment that can change your mind.

If no realistic outcome would change what you do next, you're not building an MVP. You're building version one and calling it an MVP because it sounds disciplined.

The sentence test

Before anyone writes code, finish this sentence:

"If ______ happens within ______ weeks of launch, the idea works."

Some real-shaped examples:

• "If 15 of the first 100 signups complete a booking in four weeks, the idea works."
• "If 5 of the 30 shops we onboard are still uploading inventory after a month, the idea works."
• "If people will pre-pay before the product exists, the idea works."

If you can't fill that in, that's not a failure of the exercise — it's the most useful thing the exercise can tell you. It means you don't yet know what you're testing, and every feature will look equally necessary, because there's no criterion to rank them against. That is precisely how budgets disappear.

What an MVP is not

Not a prototype. A prototype demonstrates that something could work — often clickable, often not connected to anything real. It's for showing, not for using. An MVP has real users doing real things.

Not a proof of concept. A PoC answers a technical question: can this integration work, is this algorithm fast enough. It's built for you, not for customers, and it's often thrown away deliberately.

Not a demo for investors. A demo is a sales asset. Optimising your MVP to impress an investor rather than to test demand produces something polished that teaches you nothing.

Not a bad product. This is the misreading that does the most damage. "Minimum" applies to scope, not to quality. One workflow that works reliably beats six that half-work. Users forgive a missing feature; they don't come back after a broken one.

What "minimum" actually means

Minimum means one core workflow, end to end, done properly.

Take a marketplace for booking home cleaners. The core workflow is: find a cleaner, book a slot, pay. That's it.

What feels essential and isn't, at this stage:

• An admin dashboard — you can run it from the database for the first fifty bookings
• In-app messaging — a phone number works
• Ratings and reviews — meaningless with twelve users
• A cleaner-side mobile app — a web page works
• Notifications — email works
• Multiple user roles — one for now
• Password reset flows, profile editing, settings pages — real work, zero validation value

Each of those sounds small. Together they're comfortably more than the core workflow. That's the arithmetic that surprises founders, and it's why deciding what goes in version one is the decision that sets your budget.

The examples everyone quotes, correctly

The famous MVPs are famous because they were embarrassingly small:

• Facebook launched as a way for students at one university to connect. One school, one function.
• Airbnb started with the founders renting airbeds in their own apartment, with a page built for that.
• Uber launched in one city, as a way to request a black car.

The lesson isn't "start small so you can become huge." It's that each one tested a single assumption — will people connect with classmates online, will strangers sleep in strangers' homes, will people summon a car from a phone — before building anything around it.

When you don't need an MVP at all

Worth saying, because it costs me work to say it:

• If you can validate without building anything, do that first. A landing page, a waitlist, a set of customer interviews, or pre-sales will often answer your question for a fraction of the cost. If nobody will pre-commit, that's a result.
• If the product is genuinely simple, no-code may be the right MVP. A form, a database, and some emails does not need custom engineering. No-code vs custom development is the honest comparison.
• If you already have paying customers and a clear roadmap, you're past MVP. Build the product.

What happens after

The MVP isn't the destination. You launch, you watch what people actually do rather than what they say, and you either continue, adjust, or stop. All three are successful outcomes for an experiment. Only one is a successful outcome for a product — which is exactly why treating it as a product is the expensive mistake.

Once it's running, the question becomes what to fix, what to add, and when the shortcuts you took start costing more than they saved.

If you want a second opinion on whether what you're planning is actually an MVP or a full product wearing the label, get in touch.