What Your SaaS MVP Should — and Shouldn't — Include at Launch

The word "minimum" in minimum viable product is the part everyone ignores. Founders nod along to the idea of starting small, then hand over a spec with forty screens, three user roles, a billing engine, an analytics dashboard and "oh, and it should integrate with everything." That isn't an MVP. That's a full product with the optimism turned up to maximum. And it's the single most common reason first launches arrive late, over budget, and somehow still missing the one thing customers actually wanted.

I've helped a fair number of small companies and solo founders get their first software product out the door. The technical part is rarely what trips people up. The hard part — every single time — is deciding what not to build yet. An MVP isn't a smaller version of your dream product with features sanded off at random. It's a deliberate bet: the smallest thing you can put in front of real users that proves the core idea is worth more of your money and time.

So this is the guide I wish more founders read before writing their spec. No jargon, no "move fast and break things" theatre. Just a practical way to draw the line between what belongs in your first release and what can — and should — wait.

What an MVP actually is (and what it isn't)

Let's get the definition straight, because most of the confusion starts here. An MVP is the smallest, simplest version of your product that lets a real person do the one valuable thing your product promises — and lets you learn whether they'll come back to do it again. That's it. It is a learning tool that happens to be made of working software, not a stripped-down launch of the finished thing.

The crucial word is viable. A common mistake is to read "minimum" and ship something so bare it embarrasses the user — a half-flow that crashes, a sign-up that leads to an empty screen. That's not minimum-viable, it's minimum-broken. The other failure is the opposite: a product so "complete" it took a year to build, by which point you've spent your runway proving a guess you could have tested in eight weeks.

Here's the mental test I use. For every feature on the list, ask: if we removed this, could a user still get the one core outcome the product exists for? If the answer is yes, it's almost certainly not MVP. That question alone will cut most specs in half — and the half it cuts is the half that was going to make you late.

Find the one job your product does

Before you can decide what to build, you have to be brutally clear about the single job your product does for someone. Not the vision. Not the roadmap. The one repeatable action that, if it works, makes a person's day better and makes them willing to pay. Most struggling specs are vague precisely here — they describe a platform, not a job.

Try to finish this sentence out loud: "A user comes to my product to ______, and leaves having ______." A scheduling tool: a manager comes to publish next week's roster, and leaves with every shift filled and the team notified. An invoicing app: a freelancer comes to bill a client, and leaves with a sent, trackable invoice. If you can't fill that sentence in cleanly, you're not ready to scope — you're still ready to think.

What every SaaS MVP genuinely needs

Some things are non-negotiable, even in the leanest first version — not because they're exciting, but because without them the product either can't be used or can't teach you anything. Think of these as the floor, not the ceiling. Build them simply, but build them properly.

• A way to sign in. Even a single email-and-password login is fine — but a real, secure one, because everything else hangs off knowing who the user is.
• The core workflow, end to end. The one job, from the user's first click to the moment they get the valuable outcome — no dead ends, no "coming soon" buttons in the critical path.
• Somewhere the data actually lives. Real storage, not a throwaway prototype, so a user's work survives a refresh and they can come back tomorrow.
• A way for you to see what's happening. Basic logging or a simple admin view, so when something breaks — and it will — you can find out why without guessing.
• A way for users to reach you. Even just an email link. Early users will hit edges you didn't foresee; you want them telling you, not silently leaving.
• The bare minimum of trust: a privacy note, sensible data handling, and not doing anything reckless with people's information.

Notice what's not on that list: billing, fancy onboarding, settings pages, mobile apps, integrations. We'll get to why in a moment. The point of the floor is that it's small enough to finish and solid enough to learn from. A login that works, one workflow that delivers, real data, and a way to watch and talk to users. That's a viable product.

What to deliberately leave out of v1

This is the section founders resist, so let me be blunt: most of the things that feel essential to your first launch are not. They feel essential because a "real product" has them — but you're not building a real product yet, you're building a question. Leaving these out isn't cutting corners. It's the entire discipline of an MVP.

Automated billing and complex pricing

You almost certainly do not need a self-serve billing engine, tiered plans, proration and dunning logic in version one. If early users want to pay, you can take their money manually — an invoice, a payment link, a quick call. Manual billing for your first ten customers tells you something automated billing can't: whether anyone will pay at all. Build the machine once you've proven there's money to collect.

Elaborate roles and permissions

Multi-role permission systems — admins, managers, viewers, granular access rules — are a genuine engineering swamp, and they multiply the testing surface enormously. For a first release, one kind of user is almost always enough. You'll learn the real permission needs from watching actual teams use the thing, and those needs are rarely what you'd have guessed on paper.

Integrations, native mobile apps, and the dashboard

"It needs to integrate with everything" is the phrase that quietly doubles timelines. Pick at most one integration, and only if it's part of the core job. Native iOS and Android apps can almost always wait — a responsive web app works on a phone today. And the analytics dashboard everyone wants? Users can't analyse data they haven't created yet. Ship the thing that creates the data first; visualise it once there's something to show.

A simple method to draw the line

Knowing the principle is one thing; applying it to your own spec, where every feature feels like your baby, is harder. Here's a method that works because it forces a decision on each item rather than letting everything drift into "essential."

1. 1
   List every feature you've imagined

   Dump it all out — no filtering yet. Get the full wish-list on the table so nothing lurks unspoken and reappears mid-build as a surprise.
2. 2
   Mark each one against the core job

   For each feature, ask: does a user need this to complete the one core job, end to end? Mark it 'core,' 'helpful,' or 'someday.' Be honest — most land in the last two.
3. 3
   Keep only 'core' for v1

   Your MVP is the 'core' pile and nothing else. The 'helpful' and 'someday' piles aren't rejected — they're your roadmap, parked where they belong.
4. 4
   Sanity-check the cut

   Look at what's left and ask: can a real user get real value from only this? If yes, you've scoped an MVP. If something genuinely breaks the core flow, pull just that one item back — and nothing else.

The discipline is in step four. There's always a temptation to "pull just one more thing back," and then another, until you've quietly rebuilt the full product. Allow yourself to rescue only items that genuinely break the core flow — not items that would merely make it nicer. Nicer is what version two is for.

Viable still means it has to feel real

There's a failure mode on the other side of the line, and it's worth naming. In the rush to ship small, some founders ship shabby — and call it MVP. A core flow that loses your work, a sign-up that 404s, copy full of placeholder text. That doesn't test your idea fairly; it tests whether users will tolerate a broken experience, and the answer is always no. You'll conclude the idea failed when really the execution did.

"Minimum" applies to scope, never to quality of the part you keep. Fewer features, each one solid. The one workflow you ship should feel finished — fast, clear, and trustworthy — even if it's the only thing the product does. A narrow product done well beats a broad product done badly every time, especially when you're asking strangers to trust you with their work.

The MVP isn't the finish line — it's the first reading

Here's the part that reframes everything: the launch isn't the goal. The goal is what you learn in the weeks after it. An MVP that ships and tells you "users love the core but keep asking for X" is a roaring success — even if X means a month more work. An MVP that ships into silence, with nobody coming back, has also done its job: it saved you from building the other thirty features onto a foundation no one wanted.

So plan the first weeks as deliberately as the build. Watch what people actually do, not what they say in surveys. Talk to the ones who came back and the ones who didn't. Let the real usage — not your original spec — decide what goes into version two. The roadmap you parked earlier isn't a promise; it's a hypothesis, and your users are about to grade it.

Common questions