MVP vs Full Product: What Should You Build First?

There is a strange moment in almost every software project when the product already works, but it does not quite feel like a product.

The main feature may be there. Data can be saved. The important screens exist. A user can probably complete the task the software was created for. From a purely functional point of view, it might be possible to release it.

Then the uncomfortable questions begin. What about onboarding? What happens when something goes wrong? Does the interface need another round of work? Is documentation necessary before launch? Should there be an installer? What about settings, exports, password recovery, empty states, error messages, mobile layouts, security checks and all the other things that seemed secondary when the project was still an idea?

This is where the familiar advice to “just build an MVP” becomes less simple than it sounds.

I understand the appeal of the Minimum Viable Product. Building less means reaching real users sooner. Instead of spending months developing features based on assumptions, you can put something small in front of people and discover whether the basic idea has any value.

But I have also found that the line between an MVP and an unfinished product can become surprisingly difficult to see.

The difficult question is not always “How little can I build?” Sometimes it is “How much needs to exist before this feels worth using?”

The Original MVP Was Not Simply a Small Product

The term Minimum Viable Product became widely associated with Lean Startup thinking, particularly through Eric Ries and the broader customer-development movement around startups.

Its purpose was not to encourage developers to release bad software. The idea was closer to an experiment: create the smallest version of something that allows you to test an important assumption with real users.

That distinction matters.

Suppose someone believes that freelancers would pay for a tool that automatically creates invoices from tracked work. Before building a complete accounting platform, they could create a very small version that performs that specific task. If nobody finds it useful, months of additional development may have been avoided.

In that situation, the MVP is doing its job. It is reducing uncertainty.

Over time, however, “MVP” has become a much broader term. It can describe almost anything from a clickable prototype to a functioning commercial application with fewer features than planned.

Two developers can both say they are building an MVP while creating completely different things.

One may have a landing page, a signup form and a manually operated service behind it. Another may have authentication, subscriptions, dashboards, an API, notifications and a production database. Both can reasonably use the same label.

That makes discussions about MVP development slightly confusing. The disagreement is sometimes not about product strategy at all. People are simply using the word “MVP” to mean different stages of a product.

Prototype, MVP, Beta and Full Product Are Different Questions

I find it more useful to think about product maturity as a spectrum rather than trying to decide whether something officially qualifies as an MVP.

A proof of concept may answer: Can this idea technically work?

A prototype may answer: What might the experience look like?

An MVP may answer: Will somebody actually use this solution?

A beta may ask: How does the product behave when real people use it in situations we did not predict?

A more complete product has a different problem. It needs to continue working after the interesting experiment is over.

Even this table is an approximation. Real projects rarely move through these stages as neatly as product diagrams suggest.

A product can be technically mature but commercially unvalidated. Another can have paying customers while much of its operation is still manual. A third may remain in “beta” for years while serving a large user base.

The labels are useful, but the underlying question is more interesting: what uncertainty are you trying to remove by building this version?

Why the MVP Approach Is So Attractive

Software encourages imagination. Once an idea starts growing, it is remarkably easy to imagine everything the finished system might contain.

A simple project gets user accounts. User accounts need profiles. Profiles need settings. Then perhaps teams would be useful. Teams suggest permissions. Permissions lead to roles. Someone mentions notifications. Another feature needs reporting. Before long, a small idea has acquired an admin panel, integrations, analytics and a roadmap extending into next year.

For a solo creator, this expansion is particularly dangerous because every new feature creates work in several places.

It needs to be planned, developed, integrated into the interface, tested and maintained. It may need database changes, documentation and additional error handling. It can also interact with features that already exist.

An MVP puts resistance against that expansion.

It asks whether the additional feature is necessary to test the central idea now, rather than whether the feature would eventually be useful.

There is also a psychological advantage. A smaller first version creates a visible finish line. For a project built by one person, that can matter almost as much as the technical benefits.

A product that is always three months away from completion has a tendency to remain three months away from completion.

But Users Do Not Experience Your Product Strategy

There is another side to this.

A creator may look at a release and think, “This is only the MVP. I intentionally kept it small.”

A customer does not necessarily see that distinction.

They see the product that exists in front of them.

If the navigation is confusing, they experience confusing navigation. If the installation process fails, they experience a failed installation. If there is no explanation of how an important feature works, they experience missing information.

The fact that these limitations were strategically intentional does not automatically make the experience better.

This is one reason I am cautious about interpreting “minimum” too literally. There is a difference between reducing product scope and reducing product quality.

A finance application, for example, might launch without ten different report types. That is reduced scope. Launching with unreliable calculations is something else entirely.

A project-management application might initially support only individual projects rather than complex organisations and permissions. That is a reasonable product boundary. If users regularly lose their work because saving is unreliable, calling the application an MVP does not make the problem less serious.

A small product can still feel complete. A large product can still feel unfinished.

That distinction has become increasingly important to me.

Building Self-Hosted Products Changed How I Think About “Minimum”

My own projects have made this question more complicated because I build self-hosted software that is intended to be distributed as source code.

That creates a different relationship with the first release than a typical hosted SaaS experiment.

With SaaS, the creator controls the production environment. A problem can potentially be fixed on the server and the next visitor immediately sees the corrected version. Features can be released gradually. Internal systems can remain invisible to customers.

A self-hosted source-code product leaves your environment.

Someone downloads it, installs it on their own hosting, connects it to their own database and starts working with the code. They may customise it, rebrand it or use it as a foundation for something else.

That makes some supposedly secondary features feel much less secondary.

Installation is one example. From a feature-list perspective, an installation wizard does not make a finance tracker better at tracking finances. But if a buyer cannot reliably install the application, the main features barely matter.

Documentation creates the same problem. It is tempting to treat documentation as something to write after the “real product” is finished. For source-code software, documentation is partly the interface between the creator and the person who now has to operate the application without the creator sitting beside them.

The same is true of configuration, sensible defaults and understandable error messages.

This has pushed me toward a different interpretation of an MVP. The minimum cannot be defined only by counting features. It also depends on what has to work around those features for the product to fulfil its basic promise.

The Hidden Product Around the Visible Product

When I start planning software, the visible features are usually the easiest part to imagine.

A personal finance application needs transactions, categories, savings goals and reports. A prompt-management application needs prompts, templates, collections and some way to organise them.

Those features fit nicely into a diagram.

The surrounding work does not.

• Authentication and account recovery
• Validation and useful error messages
• Empty states and first-use experience
• Responsive behaviour
• Database migrations
• Installation and configuration
• Security checks
• Documentation
• Demo data or demo mode
• Export and backup considerations
• Product screenshots and presentation
• Testing situations that were never part of the happy path

None of these sounds as exciting as adding another major feature. Together, however, they can consume a substantial part of the development time.

This is where estimates become unreliable. “The application is 80% finished” can be technically true while still leaving a surprising amount of work.

The final 20% is not necessarily polishing. Sometimes it is where a functioning collection of features becomes something another person can actually use without assistance.

When Releasing Early Really Does Make Sense

Despite those complications, there are situations where building a full product before showing it to anyone seems unnecessarily risky.

The clearest case is when the biggest uncertainty is demand.

If you do not know whether anyone wants the solution, adding twelve more features does not answer that question. It only makes the experiment more expensive.

A narrow SaaS concept is an obvious example. Perhaps the central value can be demonstrated with one workflow and a small group of test users. In that case, an MVP may reveal far more than another three months of private development.

The same applies when the product depends heavily on behaviour that is difficult to predict.

People do not always use software the way its creator imagines. A feature that appears central during planning may be ignored. A small secondary function may become the reason users return.

Real usage exposes assumptions that are almost invisible while looking at your own interface.

There is also a financial reason. Every week spent developing an untested idea has a cost, even for a solo creator who is not paying a development team. Time is still being invested, and it could have gone into another product, marketing, paid work or simply finishing something else.

When a More Complete First Release Makes Sense

The opposite case receives less attention.

Sometimes the central idea is not particularly uncertain.

If you are building another invoicing application, you probably do not need an experiment to discover whether humans need invoices. The uncertainty may instead be whether your implementation, positioning, workflow, design or distribution gives anyone a reason to choose your version.

In that situation, an extremely small MVP can test the wrong question.

A product can also operate in a category where users arrive with strong expectations. They may reasonably expect search, exports, responsive layouts, account controls or other features because comparable products already provide them.

This does not mean copying every competitor's feature list. That route can produce an enormous product before launch. It means recognising that “minimum viable” is partly defined by context.

The minimum for a new experimental tool used by twenty invited testers may be very different from the minimum for paid software sold to strangers.

Trust also matters.

Someone trying an experimental free tool may tolerate rough edges. Someone paying for downloadable software may expect the installation process, documentation and core workflows to be ready from the beginning.

Neither expectation is unreasonable.

The Cost of Shipping Too Early

“Ship early” sounds safe because the obvious alternative is perfectionism. But releasing too early has costs of its own.

The first is feedback quality.

If users struggle because basic parts of the experience are unfinished, their feedback may tell you very little about the actual product idea.

Imagine testing a new reporting tool, but half the testers cannot successfully import their data. You may conclude that people do not value the reports when the real problem is that they never reached them.

Early quality problems can also consume attention. Instead of learning whether the central idea works, you spend the test period fixing issues that were already predictable.

There is a reputation cost as well, although its importance depends heavily on the product and audience.

A private alpha can be rough because everyone understands what they have joined. A public paid launch creates a different expectation. Users may never return to see the improved version six months later.

That middle ground is easy to overlook when the discussion is framed as “launch now” versus “build for another year.”

The Cost of Waiting for the Full Product

Of course, the opposite mistake may be even easier to make when you enjoy building software.

Development gives constant evidence of progress.

Another screen is finished. Another database table works. Another feature moves from the roadmap into production. The product becomes visibly larger, which feels reassuring.

Market uncertainty does not disappear at the same rate.

A creator can spend months answering technical questions while avoiding the uncomfortable commercial question: will anyone care?

There is almost always something else that can be improved before launch. The dashboard could be cleaner. The settings page could have another option. The reports could support another filter. The documentation could contain more examples.

Each improvement can be individually reasonable.

Together, they can become a very sophisticated form of postponement.

I recognise this temptation because building is usually easier to control than releasing. Code problems may be difficult, but at least they have boundaries. A launch introduces other people, and other people are much less predictable.

This is one place where the MVP idea remains extremely useful even if the final product is intended to be substantial. It forces a question that product builders naturally avoid: Which parts of this are genuinely necessary before somebody else can see it?

AI Makes MVPs Faster — and Feature Creep Faster Too

AI-assisted development changes some of the economics of this discussion.

Features that once required several hours of searching documentation, writing boilerplate or debugging can sometimes be created much faster with AI assistance. It can help explore implementation options, draft repetitive code, explain unfamiliar parts of a codebase and suggest possible solutions.

That makes it easier for a solo creator to build something that would previously have required much more time.

It also creates a new problem.

When adding features becomes easier, saying no to features can become harder.

A feature may appear inexpensive because AI can generate a first implementation quickly. But generated code still enters the product. It needs to fit the architecture, work with existing features, handle edge cases and remain understandable later.

I have found that AI can make the first 70% of some tasks feel remarkably fast while the remaining work is still very human. Generated code may work in the obvious scenario and fail somewhere less obvious. An interface suggestion may look reasonable but not fit the rest of the application. A fix to one file may create a problem in another.

Sometimes AI saves a large amount of time. Sometimes I spend part of that saved time checking and correcting what it produced.

So AI does not remove the MVP question. In some ways it makes the question more interesting.

If ten features are now technically possible in the time that previously allowed three, does the product need ten?

Probably not.

“Full Product” Is Not a Finish Line Either

There is another problem with the comparison between MVP and full product: software is rarely full.

A product that feels complete today can acquire new requirements as soon as people begin using it. A browser changes. A dependency changes. Users request another workflow. Security expectations evolve. A feature that looked sufficient turns out to need more flexibility.

Even mature software has roadmaps.

So perhaps “full product” is the wrong mental image if it suggests that everything has been built.

I prefer to think of it as a product whose core promise is supported properly.

It does not need every possible feature. It needs enough functionality, reliability and surrounding infrastructure that the missing pieces feel like future development rather than holes in the current experience.

That is subjective, of course.

But software development contains many boundaries that cannot be reduced to a formula.

A Different Way to Decide What Belongs in Version One

Instead of asking whether a feature belongs in an MVP or a full product, I find several narrower questions more useful.

• Does the product work without this?
• Can the user complete the central workflow without it?
• Does removing it make the product smaller, or simply broken?
• Is this feature testing an important assumption?
• Is it expected because of the type of product being sold?
• Can it safely be added after users start using the product?
• Am I adding it because users need it, or because I am uncomfortable releasing?

The answers will not produce a universal feature list.

That is probably a good thing.

An MVP for a social application, a self-hosted finance system, an internal business tool and an AI writing service should not have identical standards. Their users, risks, deployment models and reasons for existing are different.

The more useful boundary may be between essential completeness and optional completeness.

Essential completeness includes what is required for the product's central promise to work reliably. Optional completeness includes the many things that could make the product broader, more flexible or more polished later.

Finding that boundary is harder than simply counting features, but it is much closer to the real product decision.

Perhaps the Better Question Is “Minimum for What?”

I started thinking about MVPs as a choice between two development strategies: build something small and launch quickly, or build something substantial and launch later.

I no longer think the choice is quite that simple.

The useful version of an MVP depends on what you are trying to learn.

If the uncertainty is whether people want the idea at all, a very small experiment may be enough. If the uncertainty is whether customers will pay for a polished alternative in an established category, the first version may need to go considerably further. If the product is distributed as source code, installation and documentation may be part of the minimum even though they are not part of the headline feature set.

And sometimes the right first version is not an MVP in the popular sense at all. It may simply be a deliberately limited product that does fewer things but tries to do those things properly.

I still like the discipline behind the MVP idea. It challenges the instinct to keep building indefinitely and reminds me that a product hidden on a development machine cannot tell me much about how other people will respond to it.

What I am less convinced by is the idea that smaller is automatically smarter.

There is a point where removing another feature makes a product focused. There is another point where removing something makes the experience incomplete. The difficult part is that nobody can draw that line for every project in advance.

Perhaps that is why the MVP vs full product question keeps returning. It looks like a question about development scope, but underneath it is really a question about uncertainty: which risks are worth resolving before launch, and which can only be resolved by finally letting the product leave your hands?