What is an MVP?

Breaking down the acronym

MVP is a term you may have heard chucked around quite a bit, or you may be reading it for the first time on my website. An MVP is an acronym for Minimum Viable Product, and it's exactly as the words describe: the minimum version of a software product that is commercially viable.

It's something you could put out on the market, advertise to your clients or customers, and get people to sign up, use, and get value from. Ideally, it would be something they're willing to pay for. Building an MVP is the first step in any product launch. Below an MVP, we've got a prototype - something that people aren't willing to really use or pay for.

The race to market

The focus of an MVP is to get something out into the market and live as quickly as possible. This urgency isn't about rushing or cutting corners - it's about reality. With software, there are unlimited options for what we can do, how your app functions, what it looks like, and how it behaves. But with so many options comes the opportunity to build something that's bloated, that does things your customers never wanted, and that they'll never use.

We want to build a version one that has the core features, solves the core business problem, and then gets people testing it to give you feedback. This is fundamentally different from trying to build the perfect product in isolation.

Why guessing doesn't work

It's incredibly difficult to guess accurately what your customers will want or how they'll use your system. Even if you know the problem well, even if you know your clients and customers inside out, even with someone experienced like me helping and directing you, we could still miss the mark completely.

We might think something is a brilliant idea to include, expecting people to love it, only to discover they hate it. Or worse, they ignore it entirely. This isn't a failure of intelligence or experience - it's the nature of building products. You can't perfectly predict human behaviour from a meeting room.

The power of early feedback

It's not uncommon to release your MVP and in the first week get feedback from five different people who all say the same thing: "It would be great if the system could do this thing that you and I never thought of." These suggestions often reveal what people actually want, not what we imagined they wanted.

This early feedback is gold. It shapes the product in directions that serve real needs rather than imaginary ones. But you can only get this feedback if you have something live that people can actually use.

The failure pattern

A big mistake with failed projects is trying to do too much in the beginning. Teams waste time and money building comprehensive solutions, only to discover they've built the wrong thing entirely. Customers wanted something different, something simpler, or something that solved a completely different problem.

I've seen projects spend 18 months building sophisticated platforms, only to launch to crickets. Meanwhile, competitors who launched simple MVPs in 8 weeks gained market share, user feedback, and revenue that funded their growth.

The MVP development cycle

Here's how the MVP approach works in practice:

Week 1-8: Build the MVP We identify the core problem and build the minimum features that solve it. No bells and whistles, just the essential value proposition.

Week 9-12: Launch and gather feedback We get the MVP in front of real users. This isn't a beta test - it's a commercial launch at a potentially reduced price point.

Week 13+: Iterate and improve Based on actual usage data and user feedback, we prioritise what to build next. The product evolves based on reality, not assumptions.

The self-funding model

The beauty of the MVP approach is that it becomes self-sustaining. We launch within 8-12 weeks, get paying customers, and use their licence fees to develop the product further. It starts very small and grows organically.

This approach keeps initial capital investment minimal while proving the concept with real money from real customers. It's infinitely more reliable than burning through investment based on assumptions.

What MVP doesn't mean

Let me be clear about what MVP doesn't mean:

It's not a prototype: A prototype is for testing concepts. An MVP is for serving customers.

It's not unpolished: The features you include should work brilliantly. You're just not including every possible feature.

It's not permanent: The MVP is version one. It will evolve based on user feedback and business needs.

It's not feature-light by accident: Every feature decision is intentional. We're not cutting features because we're lazy; we're cutting them because they don't serve the core purpose.

The alternative approaches

Unless you're targeting Silicon Valley-style rounds of big investments and planning to take over the tech world, the MVP approach makes the most sense. If you're building a SaaS product for your clients or customer base, possibly to attract new ones, then starting small is the smart play.

The alternative - trying to build everything upfront - is expensive, risky, and usually leads to building the wrong thing. It's better to be right about something small than wrong about something big.

MVP in practice

A good MVP might have:

• User authentication and basic account management
• One core workflow that solves the primary problem
• Basic reporting or dashboard functionality
• Simple billing integration
• Essential admin features

A bad MVP tries to include:

• Advanced analytics dashboards
• Complex permission systems
• AI-powered recommendations
• Multiple integrations
• Sophisticated automation

The difference isn't quality - it's focus. The good MVP does fewer things, but does them well enough that customers will pay for them.

The mindset shift

Building an MVP requires a mindset shift from "What could this product do?" to "What must this product do?" It's about solving one problem really well, not solving every problem adequately. This focused approach is particularly effective when using modern development frameworks that allow for rapid iteration.

This approach has helped my clients launch successful products while competitors were still in development. They gained market share, user feedback, and revenue while others were still guessing what to build.

Getting started

If you're considering building a software product, start with defining your MVP. What's the absolute minimum that would be commercially viable? What's the core problem you're solving? What features are essential versus nice-to-have?

Answer these questions honestly, and you'll have a much clearer path to launch. Start small, launch quickly, and let real users guide your product development. That's the MVP approach, and it works.