SaaS MVP: What to Include and What to Cut

A SaaS MVP should include exactly four things: authentication, one core workflow done well, a way to take payment, and a bare-bones admin view. Everything else is a candidate to cut until real users prove you need it.

Most first-time founders get the MVP backward. They spend months building settings pages, role hierarchies, integrations, and a marketing site before a single person has paid them a dollar or completed the one action the product exists to enable. The result is a slower path to revenue, a slower path to learning, and a codebase that is expensive to change right when you most need to change it. This article lays out a practical way to decide your SaaS MVP features — what belongs in version one, what to defer, and how to make cutting decisions without arguing about them for weeks.

What does "MVP" actually mean for a SaaS product?

An MVP is the smallest product that lets a real customer complete a real job and pay you for it. The emphasis is on minimum and viable in equal measure. Minimum means you strip away everything that is not required to deliver the core value. Viable means it actually works end to end — a paying user can sign up, do the thing, and get value without you standing over their shoulder.

That second half is where a lot of "MVPs" fall down. A pile of half-finished features is not viable. A landing page with a waitlist is a validation experiment, not an MVP. The MVP is the first version that a stranger can use and pay for. Your goal is to reach that point with the least code you can responsibly ship, so you start collecting revenue and, more importantly, evidence about what to build next.

What are the must-have SaaS MVP features?

For nearly every B2B SaaS product, the non-negotiable core is short. Build these, and resist adding a fifth category until the first four are solid.

• Authentication and accounts. Users need to sign up, log in, and reset a password. Keep it boring: email and password, or a single social/SSO provider if your audience expects it. You do not need multi-factor auth, team invitations, or granular roles on day one.
• The one core workflow. This is the reason the product exists — the single sequence of steps that delivers your value. If you sell invoicing software, it is "create an invoice and send it." If you sell scheduling, it is "share availability and book a slot." Build this one path deeply and make it genuinely good. Everything else is scaffolding around it.
• Billing. If you want to know whether people will pay, you have to let them pay. Wire up a payment processor like Stripe, pick one or two simple plans, and handle the basics: subscribe, charge, and cancel. Skip proration edge cases, annual/monthly toggles, coupons, and dunning flows until they matter.
• Basic admin. You need a way to see who signed up, look at their data when they email support, and fix things manually. This can be as simple as a protected internal page or even direct database access in the very early days. It exists so you can run the business, not so customers can self-serve every setting.

That is the whole list. Auth, one workflow, billing, admin. When founders ask us to scope a first release as part of our custom software work, this is the frame we start from — and the hard conversations are almost always about what to remove from their wish list, not what to add.

What should you cut or defer from the first version?

The cut list is longer than the keep list, and that is the point. Here are the features founders most often want to build early that can almost always wait.

• Team and role management. Multi-seat accounts, permissions, and admin-vs-member distinctions are real work and rarely needed to prove value. Start with single users or a single shared login and add teams once customers ask.
• Integrations. Every "connect to Slack / Salesforce / QuickBooks" integration is its own mini-product with its own auth, error handling, and maintenance. Ship none at launch unless one specific integration is the core value.
• Deep settings and customization. Theming, custom fields, configurable workflows, and notification preferences feel professional but add surface area you will have to support forever. Pick sensible defaults instead.
• Analytics dashboards for users. Charts and reports are seductive and slow to build. Most users want the core job done first; give them a dashboard once they are relying on the product daily.
• Onboarding tours, in-app messaging, and gamification. These optimize retention for a product people already use. You do not have that yet.
• Mobile apps. A responsive web app covers most B2B use cases at launch. Native apps are a large, separate investment.
• Premature scale work. Microservices, multi-region infrastructure, and heavy caching solve problems you do not have at ten customers. A single well-structured application on managed hosting is plenty.

Deferring is not the same as deleting. Keep a parking lot — a simple list of everything you decided not to build and why. When a real customer asks for one of those items, it moves up. That way cutting feels like sequencing, not sacrifice, and nobody feels their idea was thrown away.

What framework helps you decide what to cut?

Arguing feature-by-feature from opinion is exhausting and tends to reward whoever is most stubborn. A simple test cuts through it. For every proposed feature, ask three questions in order:

1. Does the core workflow work without it? If a user can still complete the main job and get value, the feature is not core. It waits.
2. Will a paying customer refuse to buy without it? Not "would it be nicer" — will the sale genuinely not happen? Be honest, and where you can, ask a real prospect rather than guessing. Most features fail this test.
3. Does it block you from charging money? If the absence of the feature means you literally cannot collect payment or deliver the paid outcome, it stays.

If a feature does not clearly pass one of those three, it goes on the parking-lot list. A useful companion is the "one core workflow" rule: write down, in a single sentence, the main thing your product does. Then for every screen and button, ask whether it directly serves that sentence. If it does not, question it hard.

Another lens is the effort-versus-evidence trade. Early on, your scarcest resource is not features — it is knowledge about what customers actually value. Prefer whatever gets you real usage and feedback fastest, because that evidence is what tells you where to spend the next month of build time. A feature that takes three weeks and teaches you nothing is a worse investment than a rough one that ships in three days and produces a dozen customer conversations.

What are the most common over-building mistakes?

The same patterns show up again and again when we audit stalled early-stage products.

• Building for a scale you do not have. Designing for a million users when you have zero. The architecture you need at ten customers is simple, and you will learn far more about your real bottlenecks by getting there than by guessing in advance.
• Perfecting the admin and settings before the core. It is comfortable to build CRUD screens and configuration toggles because the requirements are clear. But comfort is not the same as value. If the core workflow is not excellent, no amount of settings will save the product.
• Gold-plating the core workflow itself. Even the thing that matters can be over-built. You do not need every edge case, keyboard shortcut, and animation in version one — you need the happy path to work reliably.
• Confusing "founders would use it" with "customers need it." Founders are power users who imagine every advanced case. Your first customers usually want the simple case done well.
• Rebuilding commodity infrastructure. Writing your own auth, billing engine, or email delivery instead of using proven services. Buy these; do not build them.
• Endless polish before launch. Treating the launch date as a moving target that recedes every time someone thinks of one more thing. Ship, then iterate against reality.

How does a tight MVP get you to revenue and learning faster?

The two things a young SaaS company is desperate for are money and information, and a tight MVP produces both sooner. Because you build four categories instead of fourteen, you ship in weeks rather than quarters. Because you ship, real users touch the product — and real usage tells you things no roadmap meeting can: which parts of the workflow confuse people, which feature requests actually repeat, and whether anyone will pay.

That feedback loop compounds. Every week you are live, you are collecting evidence that makes your next decision cheaper and more accurate. Meanwhile the founder who spent six months building the "complete" product is making all of those decisions blind, and has a large, entangled codebase that is expensive to change once the market inevitably surprises them. A smaller codebase is also faster to modify, so when the evidence says "pivot the workflow," you can.

Revenue matters here beyond the cash. A customer who pays — even a small amount — is giving you the strongest possible signal that the value is real. Free users are polite; paying users are honest. Getting to that signal quickly is the entire point of keeping the MVP tight.

A practical launch checklist

Before you call something an MVP and put it in front of paying customers, run through this list:

• A stranger can sign up and log in without help.
• They can complete the one core workflow from start to finish.
• They can pay you, and the subscription actually activates.
• You can see new signups and look up a user's data to support them.
• Errors in the core path are handled gracefully, not with a white screen.
• You have a way to collect feedback — an email address is fine.
• Every feature you cut is written down in a parking lot for later.

If all seven are true, you are ready. If you are adding items to this list, ask whether each one passes the three-question test above. For a deeper look at scoping and sequencing a build, our team also writes about this in our insights library.

Frequently asked questions

How long should it take to build a SaaS MVP? With a tightly scoped feature set, a focused team can usually ship a genuine MVP in roughly one to three months. If your estimate is six months or more, that is a strong sign the scope is too big and some "must-haves" are actually deferrable.

Should the MVP be free or paid? Paid, in almost every case. The point of an MVP is to learn whether people value the product enough to pay, and you cannot learn that if nothing is priced. A free tier can come later once you understand your value and your costs.

Do I need integrations in my MVP? Only if a specific integration is the core value — for example, a product whose entire job is syncing two tools. Otherwise, integrations are the classic thing to defer until customers ask for a specific one.

What if a competitor already has more features? That is usually an advantage for you. A focused product that does one job better than a bloated competitor is a real wedge. You do not win by matching their feature list; you win by being clearly better at the thing that matters most.

How do I handle customers who ask for a feature I cut? Log it, tell them it is on the list, and watch how often the request repeats. Frequent, specific requests from paying customers are exactly the signal you built the MVP to collect. Build in response to that evidence, not to a single loud voice.

The bottom line

A strong SaaS MVP is defined as much by discipline as by code. Include authentication, one core workflow done well, billing, and basic admin. Defer teams, integrations, deep settings, dashboards, and scale work until real customers prove you need them. Use the three-question test to keep decisions objective, and treat every cut as sequencing rather than sacrifice. Do this, and you reach revenue and real learning in weeks instead of months — with a codebase nimble enough to act on what you learn.

If you are scoping a SaaS MVP and want a partner who will push back on the feature list as hard as they build it, we would like to help. Reach out at our contact page and let's define the smallest version of your product that can start earning and teaching.