SaaS MVP Checklist: What Should You Build First?

Ask five people what an MVP needs and you'll get five versions of the same list: sign up, log in, a dashboard, payments, maybe an admin panel. That list isn't wrong, exactly. It's just not useful. It tells you what most software has, not what your software needs first.

The better question isn't "what features does an MVP have". It's "what does this specific business need to prove before it spends more money?" That's the checklist I actually work through with founders before I write a line of code.

Start with the risky assumption, not the feature list

Every new product rests on an assumption that might be wrong. Will people pay for this? Will they actually use it weekly, or just sign up and forget? Will the workflow you've imagined match how people really work?

An MVP's job is to test that assumption as cheaply as possible. Everything else is scaffolding. If you're not sure what your risky assumption is, ask yourself: what would make me shut this down? That's usually the thing to build and test first.

For a booking app I built for tradespeople (you can see it as Patch), the risky assumption wasn't "can we build a calendar". It was "will customers actually pay a deposit through a link before the appointment happens". So that flow, and the payment behind it, came before anything else. The branding, the reminders, the recurring job scheduling, all of that came after the core loop was proven.

What almost every MVP genuinely needs

• One complete core workflow. Not five half-finished ones. Pick the single job your product does and make it work end to end, properly, not as a demo.
• A real way to take money, if money is the point. If your business model depends on payment, put actual payment in from day one. A "coming soon" pricing page tells you nothing about whether people will pull out a card.
• Just enough account and data structure. You need somewhere to store a user and their data, but you don't need roles, permissions, teams or invite flows unless the very first version genuinely requires them.
• A way to see what's happening. Not a dashboard with charts, just enough visibility (even a spreadsheet export or an admin-only screen) that you can watch how people actually use it.

What you can safely leave out at first

• Admin panels and back-office tooling. If you're the only admin, a database viewer or a handful of manual queries will do the job for months.
• Notifications and reminders. Useful, rarely essential to prove the core idea. Add them once you know people are using the thing you'd be reminding them about.
• Third-party integrations. Every integration is a dependency that can break later (I've written before about what happens when an API you rely on changes). Wire up the one integration that's non-negotiable, defer the rest.
• Multi-tenant complexity. If you're planning to sell to agencies or teams eventually, resist building full team permissions before you have a single team asking for it.
• A native mobile app. A responsive web app, or a progressive web app that installs like one, gets you the same first impression without doubling your build.

The part people get wrong: cutting the wrong corner

There's a difference between skipping a feature and skipping the structure underneath it. Leaving out an admin panel is fine. Leaving out a proper data model because you're in a hurry is not, because that's the part that's expensive to fix later. If your MVP stores customer records, bookings, or transactions, the underlying tables need to be right even if the screen showing them is basic. I've seen products slow to a crawl months in because the shortcuts taken early were in the data layer, not the UI (the classic version of this is the N+1 query problem, which rarely shows up until you have real users and real data).

The rule I use: cut visible features freely, cut structural decisions carefully. A missing settings page costs you an afternoon later. A wrong database schema can cost you a rebuild.

Concierge first, automate second

If a part of your workflow is genuinely hard to build well but only happens a handful of times a week at first, it's often smarter to do it manually behind the scenes rather than automate it in version one. Send the confirmation email yourself. Manually match the order to the supplier. Nobody using your MVP needs to know that a human, not a system, handled that step, so long as it happens reliably. You only automate it once you know it's worth automating.

This is one of the advantages of working with one experienced developer rather than a larger build: I can tell you honestly which parts are worth automating now and which parts you should do by hand for the first few months, because I'm not trying to fill a sprint or justify a bigger scope.

A short version of the checklist

• Name the one assumption this MVP needs to prove.
• Build that one workflow properly, end to end.
• If money changes hands, take real payment from day one.
• Get the data model right, even if the screens are plain.
• Do manually what you don't yet need to automate.
• Leave out admin tools, notifications, integrations and permissions until someone actually asks for them.

If you're not sure where your list should start, it's worth writing the brief down properly before you talk to anyone about a quote. My Software Brief Generator walks through exactly this kind of prioritising, and turns it into a document you can hand to any developer, including me.

I scope SaaS MVPs this way as standard: work out the risky assumption first, build only what's needed to test it, and be honest about what can wait. You can see some of what that's produced in my case studies, or get in touch directly if you want to talk through where your own MVP should start.