Overview

A minimum viable product is meant to be the smallest version of your SaaS that real customers can use to solve a real problem. In practice, many MVPs either grow into a year-long build that tries to do everything, or get cut so far that nobody can get value from them.

A good MVP scope sits between those extremes. It delivers one complete outcome for one clearly defined customer, and includes the unglamorous parts that let you charge for it and support it. Here is a practical way to define that scope.

Define one customer and one outcome

Start with a single sentence: who the product is for and what it helps them achieve. For example, "Independent accountants can collect documents from clients without chasing them by email." That sentence becomes the test for every feature request.

If a feature does not help that customer reach that outcome, it belongs on the later list. This feels restrictive, but a narrow, well-served audience gives you clearer feedback than a broad one served poorly.

Map the core journey from start to finish

Write down every step a new customer takes, from first visit to receiving value and coming back. An MVP needs each step to work, even if some are basic. A journey that breaks halfway is not viable, however polished the first screens are.

For most SaaS products the journey looks broadly like this, and each step should have a named owner in the build plan.

  • Discover the product and understand what it does.
  • Sign up, verify an email address and log in securely.
  • Complete a short onboarding that sets up the essentials.
  • Perform the core task the product exists for.
  • See the result, and get notified when something needs attention.
  • Pay, upgrade or cancel without contacting support.

Include the SaaS foundations early

Some parts of a SaaS product are hard to add later, so they belong in the MVP even though customers rarely notice them. The most important is the data model for accounts. Decide whether customers are individuals or organisations with several users, because retrofitting multi-user workspaces onto a single-user design is painful.

Billing is the other foundation. Using a provider such as Stripe or Razorpay for subscriptions, invoices and failed-payment handling saves months of work. Even if you start with one plan, build it so that more plans can be added without rewriting the logic.

  • Authentication with password reset and, ideally, single sign-on later.
  • Organisation or workspace model with roles such as owner and member.
  • Subscription billing through a payment provider.
  • Transactional emails for sign-up, invites, receipts and alerts.
  • Basic audit logs and error monitoring.

Build an internal admin, even a plain one

Founders often forget that someone has to run the product. You will need to look up a customer, extend a trial, issue a refund, reset a stuck account or see who signed up this week. Without an admin view, every one of those tasks becomes a database query or a developer request.

The admin does not need to be beautiful. A searchable list of accounts, their plan, their status and a few safe actions is usually enough at launch.

Decide what you will deliberately leave out

A written list of exclusions is as useful as the feature list. It stops scope creep and gives you a ready answer when a prospect asks for something. Common candidates for later include native mobile apps, advanced reporting, a public API, a marketplace of integrations, white-labelling and complex permission systems.

Manual processes are a legitimate MVP tool. If only a handful of customers need a data import, a team member can do it by hand at first. Automate it once you know it is worth automating.

Plan how you will learn from the first users

An MVP is a learning tool, so build in the means to learn. Add product analytics for the key steps in the journey, so you can see where people drop off. Give users an easy way to send feedback from inside the app, and talk to early customers directly.

Decide in advance what would count as a signal to continue, change direction or stop. Agreeing these questions before launch makes it much easier to read the results honestly afterwards.

A quick scope check

Before development starts, review the scope against a short list of questions. If you can answer yes to each one, the MVP is probably well-shaped. If not, adjust the plan before writing code, when changes are still cheap.

  • Can a new customer go from sign-up to value without your help?
  • Can you take payment and handle a cancellation?
  • Can your team support customers without touching the database?
  • Is every feature traceable to the core customer and outcome?
  • Do you know which metrics will tell you whether it is working?
Have a project where this applies? Let’s discuss it