An MVP, or minimum viable product, is the smallest version of your product that real customers can use and pay for. For a SaaS product, that means a working service people log into, not a demo or a slide deck. The goal is to learn fast and cheaply what customers value, while laying foundations you will not have to tear down later.
This guide covers the planning steps we go through with founders before a line of code is written.
Start with one customer and one problem
Most MVPs fail because they try to serve everyone. Pick a specific first customer: not "small businesses", but "physiotherapy clinics with two to ten therapists that book by phone". Then write down the one problem you will solve for them and the outcome they will see.
A useful test is to finish this sentence: "After using our product for a month, a customer will be able to ___ without ___." If you cannot finish it in one line, the scope is not clear yet.
List every feature, then cut hard
Write down every feature you imagine for the full product. Then go through the list and ask one question for each item: could the first customer solve the core problem without it for the first three months? If the answer is yes, it waits.
Typical features that can wait include advanced settings, detailed reports, multiple integrations, mobile apps, team roles beyond admin and member, and anything aimed at a second type of customer. Typical features that cannot wait are the core workflow, the data the customer needs to see, and the way they get their data in.
Aim for a list short enough that you could explain every item to a customer in a single call. Keep the rest in a separate list for later, so good ideas are not lost.
Build the foundations properly
"Minimum" applies to features, not to quality. Some parts of a SaaS product are cheap to build right at the start and expensive to fix later. These belong in the MVP:
- A clear data model. Think through the main records, such as accounts, users, customers and bookings, and how they relate. Changing this later touches everything.
- Accounts and permissions. Secure sign-up, sign-in, password reset and at least two roles. See user authentication.
- Tenant separation. If business customers will share one system, every record must belong to a customer account, and every request must check it. Read multi-tenant SaaS architecture explained.
- Billing. If you charge subscriptions, set up plans, trials and failed payment handling from the start.
- Basic operations. Backups, error tracking, simple monitoring and a repeatable deployment.
Design the core flow before building
Sketch the screens a customer uses to get from sign-up to the outcome you promised. Simple wireframes are enough. Walk through them with two or three potential customers and watch where they hesitate.
This step takes days, not weeks, and it catches the most expensive mistakes: missing steps, confusing order and features that turn out not to matter. It also makes development estimates far more accurate.
Decide on pricing early
Pricing is part of the product, not an afterthought. Decide how you will charge: per user, per account, per usage or a flat fee. Keep it simple for the MVP, with one or two plans. Charging from day one, even a modest amount, tells you much more than free sign-ups do.
If you are unsure, offer a paid plan with a short trial, and talk to everyone who signs up. See how to add subscriptions and billing to a SaaS.
Plan the build in short cycles
Break the MVP into small pieces that can each be shown working. Work in one- or two-week cycles, with a demo at the end of each. That keeps everyone aligned and lets you adjust as you learn. Write the plan down in a short requirements document, so any team can estimate it. See how to write a software requirements document.
With AI-accelerated development, routine parts such as forms, lists and tests are built faster, which leaves more of the budget for the parts that need judgment: the core workflow, the data model and testing with real users.
Plan the launch as a learning exercise
An MVP launch is not a big announcement. It is the start of a feedback loop. Invite a small group of customers who match your first customer profile. Help them set up personally. Watch how they use the product and talk to them every week.
Before launch, write down the two or three questions you want answered, for example:
- Do customers complete the core workflow without help?
- Do they come back every week?
- Will they pay at the price we set?
What to measure after launch
Keep metrics few and meaningful. Track activation, meaning the share of sign-ups who complete the core workflow once, weekly use of the core feature, conversion from trial to paid and cancellations with their reasons. Tools that group feedback by theme help you see patterns early. See customer feedback analysis.
Then let those answers decide the next features. Most successful products look quite different a year after their MVP, because they followed what customers actually did.
Common mistakes to avoid
A few mistakes come up again and again. The first is building for several customer types at once, which spreads the product thin and makes every decision harder. The second is polishing features nobody has asked for while the core workflow still has rough edges. The third is launching to the public without a way to talk to users, so the product goes live and the team learns nothing.
Another common one is treating the MVP as disposable. If the plan is to "rebuild properly later", the rebuild usually never comes, and the shortcuts become permanent. Build a small product well, then grow it. The customers who join early will remember whether the product was reliable, even if it was simple.
Working with a development partner
If an outside team is building your MVP, share the customer, the problem and the learning questions, not only the feature list. A good partner will challenge scope, suggest cheaper ways to test ideas and explain which foundations matter. Agree on short cycles with demos, and make sure the code and accounts belong to you from the start. See how to choose a development partner.
SaaS MVP planning checklist
- First customer and core problem written in one sentence each.
- Feature list cut to what the core workflow needs.
- Data model, permissions, tenant separation and billing planned.
- Wireframes of the core flow tested with real people.
- Pricing and plans decided.
- Build broken into short cycles with demos.
- Launch group, learning questions and metrics agreed.
For the trade-offs of starting small, read MVP vs full product.