Scoping a SaaS MVP: what to build first.
Most first-time SaaS founders build 3x more than they need. A practical method for cutting scope without cutting the product's reason to exist — from platforms we've taken to launch.
Every SaaS project we scope starts the same way: a founder with a feature list three times longer than their budget. That's not a criticism — it means they can see the product clearly. But the difference between a launch and an expensive stall is what you're willing to not build yet.
The one-sentence test
Before any feature discussion, finish this sentence: "[Audience] uses [product] to [outcome]." "Muslim educators use Miftah to run their courses and community in one branded space." Everything in the MVP must serve that sentence directly. Everything that serves a different sentence — a second audience, a second outcome — is a different release.
Sort every feature into three lists
- The reason to exist — remove it and the one-sentence pitch is false. Build this.
- The cost of doing business — auth, payments, account settings, the admin panel. Build the boring minimum; buy or integrate where possible.
- The someday list — everything users could live without for six months. Write it down, date it, and don't build it.
The discipline is in list two. Founders under-scope the unglamorous plumbing (a real admin panel always takes longer than expected) and over-scope the visible surface (three onboarding flows where one would do).
What actually belongs in v1
When we built Miftah, the temptation was to launch with courses, live sessions, forums, memberships, analytics, and mobile apps simultaneously. The launch version instead did the core loop excellently: create a course, enrol members, run the community, take payment. Features earn their way in by users asking — analytics dashboards mean nothing before there's activity to analyse.
Scope the operations, not just the product
First-time founders scope what users see and forget what they will need to run it: refunding a payment, resetting an account, seeing signups, moderating content. If day-one operations require a developer to run database queries, support will consume your build capacity. A thin admin panel in v1 pays for itself in the first month.
The budget shape that works
Plan the spend as 60 / 20 / 20: sixty percent to the core loop, twenty to operations, and twenty held back for what you learn in the first weeks after launch. That last tranche matters most — real users always reveal one blind spot, and the founders who reserved budget for it iterate while their competitors wait for a new funding round.
An MVP isn't the cheapest version of your product. It's the smallest version of your point.
Cut scope until what's left is unmistakably the point — then build that part properly. Rough edges are forgivable at launch; a blurry reason to exist is not.
