Building a SaaS MVP: What to Include and What to Cut

The MVP question isn't what features — it's what risk are we testing

The best framing for saas mvp development isn't a feature list, it's a hypothesis: what does this product need to prove to real customers to justify the next round of investment or the next six months of work? Every feature decision should trace back to that question, and most founders we work with start from the opposite direction, listing every feature the eventual product will need and then negotiating down from there, which almost always produces an MVP that's still too big and too slow to ship.

We push clients to define the one workflow that, if it worked well, would prove the product deserves to exist, and to be genuinely ruthless about deferring everything that isn't load-bearing for that specific proof.

Include: the core workflow, end to end, even if narrow

The MVP has to let a real user complete the actual job the product exists to do, start to finish, even if that path is narrow and unglamorous compared to the eventual vision. A project management SaaS MVP doesn't need twelve view types, it needs one view type that lets a team actually manage a project, built well enough that a real team would choose to keep using it. Breadth across many half-built features tests nothing; depth on the one path that matters tests exactly the thing you need an answer to.

Deciding which workflow is core also means being honest about who the first real user actually is, not the eventual ideal customer profile a deck describes, but the specific person who will use the product in its first month. We've seen MVP scope balloon because a founder tried to build for three different eventual customer segments simultaneously, each needing a slightly different version of the core workflow, when the actual first cohort of real users needed only one of those versions to prove the concept. Picking one version, shipping it well, and explicitly deferring the other segments until there's evidence the first one works is what actually gets an MVP built in ninety days instead of nine months.

Include: auth, billing, and basic admin — the unglamorous non-negotiables

Auth, billing, and basic admin tooling aren't exciting, and they're also not optional, because a SaaS product without them isn't actually a SaaS product, it's a prototype you can't charge for or support. We build these in from day one specifically because retrofitting billing onto a product that already has paying customers, or bolting auth onto a shared-account internal tool, is genuinely harder than building them correctly from the start. Basic admin, the ability for someone on the team to look up a customer's account and fix a stuck state without writing a database query by hand, belongs in the MVP too, because you will need it in week two, not month six.

Cut: customization, integrations, and anything speculative

Configurable workflows, white-labeling, an integrations marketplace, granular permission tiers, these are what customers ask for once they're already paying you, and building them speculatively before you have paying customers means guessing at requirements you don't have real evidence for yet. We cut these hard in MVP scoping, not because they're unimportant, but because they're expensive to build correctly and cheap to add once actual customer requests tell you which version of customizable you actually need to build.

An MVP isn't the smallest version of your product. It's the smallest thing that can prove your product's core assumption is true or false, everything else is scope you're paying for before you know if you need it.

Cut, usually: a native mobile app before the web product proves itself

Founders frequently want a native mobile app in the MVP because it feels like table stakes for a modern product, but for most B2B SaaS, the buyer and daily user are at a desk, and a responsive web app covers that need completely at a fraction of the cost and timeline of native. We steer clients toward proving the product on web first and building native mobile once there's a demonstrated, specific reason users need it on their phone, not because mobile isn't valuable, but because building it speculatively, before you know which mobile workflows actually matter, means building the wrong native app.

How we scope this conversation with clients

Every SaaS MVP scoping conversation we run starts with the same question, asked directly: what has to be true after this ships for you to know whether to keep going? The features that answer that question make the cut. Everything else goes on a clearly written, not-forgotten backlog, which matters as much as the cutting itself, founders trust the cut more when it's explicit that later is a real plan, not a euphemism for never, and a 90-day MVP timeline only works when the scope was actually disciplined enough to fit inside it.

If you're scoping something like this, see our SaaS platform development.