What to Include in an MVP (and What to Leave Out)

An MVP should include the one core workflow that delivers value to a specific user, end to end, plus the minimum foundations needed to run it responsibly: sign-in if required, security basics, analytics to measure the outcome, and a way to collect feedback. Everything else, including secondary features, extensive settings, and edge-case automation, can wait until real usage tells you it matters. The aim is to test your riskiest assumption with the least work, not to ship a smaller version of the full vision.

What is an MVP, really?

A minimum viable product is the smallest thing you can put in front of real users to learn whether your core idea works. Minimum refers to scope. Viable means it must actually solve the problem well enough that people will use it and you can learn from their behavior. A buggy, confusing product does not test your idea; it tests users' patience.

Cut breadth, not quality. One complete, reliable path beats ten half-finished ones.

Start with the riskiest assumption

Every product rests on assumptions: that a problem is painful enough, that a specific user will change behavior, that they will pay, or that a technical approach is feasible. List them and rank them by how uncertain they are and how fatal it would be if they were wrong. Your MVP exists to test the top one or two.

• Desirability: will the target user actually use this instead of their current workaround?
• Viability: will someone pay, or does the business model hold up?
• Feasibility: can the critical piece, such as an AI feature or an integration, work reliably enough?
• Usability: can people figure it out without hand-holding?

Sometimes the cheapest test is not software at all. A clickable prototype, a landing page, or a manually operated service behind a simple interface can answer desirability questions before you build anything.

Define one user and one core job

Pick a narrow primary user and the single job they hire your product to do. Write it as a sentence: a freelance designer needs to send a professional invoice and get paid without chasing clients. That sentence becomes the filter for every feature decision. If a feature does not help that user do that job, it is out of scope for now.

What should an MVP include?

The core workflow, end to end

Map the steps from first visit to the moment of value, then build each step simply but completely. A user should be able to arrive, understand the product, complete the core job, and see the result without dead ends.

Non-negotiable foundations

• Authentication and authorization done properly, ideally with a proven provider rather than custom code.
• Security basics: encrypted connections, safe handling of personal data, and sensible access controls.
• Analytics on the key events in the core workflow, so you can measure activation and retention.
• Error tracking and logging, so you find problems before users report them.
• Accessible, responsive layouts that work on the devices your users actually have.
• A feedback channel: in-app prompts, a simple form, or direct contact with early users.
• Legal essentials such as a privacy policy and terms appropriate to your market.

What to leave out of an MVP

• Multiple user roles and permissions beyond what the core job needs.
• Extensive settings, customization, and theming.
• Integrations other than the one or two the core workflow depends on.
• Admin dashboards that a database tool or simple internal page can replace for now.
• Native apps on every platform when a responsive web app can test the idea.
• Automation of rare edge cases that you can handle manually at low volume.
• Premature scaling work, such as microservices or complex infrastructure.

How to prioritize features

Write every candidate feature on the board, then sort them against the core job. A simple approach is to label each as must-have for the core workflow, should-have to make it pleasant, or later. Be strict: a must-have is something without which the user cannot complete the job at all. Story mapping, which lays out the user journey horizontally and stacks features under each step, makes it easy to draw a line across the board for the first release.

Technical choices that keep you moving

• Choose mainstream, well-documented technologies your team knows well.
• Use managed services for hosting, databases, authentication, email, and payments.
• Keep the architecture simple, typically a single application and a relational database such as PostgreSQL.
• Write tests for the critical paths, such as payments and data integrity, even if coverage is light elsewhere.
• Avoid shortcuts that are expensive to undo, like weak data models or no migration strategy.

Define success before launch

Decide in advance what result would make you continue, change direction, or stop. Choose a few measurable signals tied to your riskiest assumption, such as the share of new users who complete the core job, how many return within a set period, or how many convert to paid. Pair numbers with conversations: talk to early users about what they expected, what confused them, and what they would miss if the product disappeared.

After the MVP

An MVP is a beginning, not a finish line. Use what you learn to decide the next most valuable step, which may be deepening the core workflow, widening to a second user type, or rethinking the approach. In discovery, we usually leave the first planning session with a one-page scope: the user, the core job, the riskiest assumption, the must-have features, and the success signals. It keeps everyone honest when the temptation to add just one more feature arrives.