Scoping a SaaS MVP: What to Build First and What to Cut

The word "MVP" has been stretched until it means nothing. For some people it's a landing page. For others it's a full product with a smaller marketing budget.

Here's a definition worth using: the smallest thing you can build that lets a real person get real value and pay you for it.

Every word there is doing work. Real person, not a friend doing you a favor. Real value, not a demo. Pay you, because that's the only signal that reliably means anything.

The foundation you can't skip

Before any feature that makes your product distinctive, there's a layer of work that every SaaS needs and nobody demos.

• Authentication. Sign-up, login, password reset, sessions. Reset flows alone take longer than anyone expects.
• Accounts and permissions. If more than one person from a company uses it, you need teams and roles. Retrofitting multi-tenancy later is one of the most expensive rewrites in software — the data model has to change underneath live customers.
• Billing. Subscriptions, failed payments, plan changes, cancellation. Payment providers handle the card; you build everything around it.
• An admin view. So you can see accounts, fix problems, and answer support questions without running database queries by hand.
• Transactional email. Verification, resets, notifications. Deliverability is its own problem.

This is commonly a third to a half of an MVP's build time, and it's invisible in every demo. Founders consistently underbudget it because it isn't the interesting part.

The one decision to get right early is multi-tenancy. If there's any chance teams will use this, build for it from day one. Almost everything else can be added later at reasonable cost. That one can't.

Deciding what makes the cut

The useful question isn't "what should the product do?" It's "what's the single workflow where this is better than the spreadsheet they use now?"

Build that workflow properly, end to end, for one type of user. Then stop.

A practical filter — for each proposed feature, ask:

1. Can a user get value without it? If yes, cut it from v1.
2. Is there a manual workaround? If you can do it by hand for your first twenty customers, do that. Manual processes are cheaper than code and teach you what to automate.
3. Does removing it break the core workflow? If yes, it stays.

That second one is underused. Your first customers will tolerate a lot of manual behind-the-scenes work in exchange for solving their problem, and every manual process you run teaches you something you'd have guessed wrong in code.

The features that always get cut, so cut them early

From most MVP builds, these can nearly always wait:

• Deep analytics dashboards. Customers say they want them. They rarely open them. Ship one number.
• Bulk import and export. Needed eventually, not by customer three. Do it manually for them, and you'll learn what their data actually looks like.
• A public API. Almost nobody asks for it in the first six months.
• SSO and enterprise features. Only when an enterprise deal is actually on the table.
• Mobile apps. A responsive web app covers it initially.
• Granular notification preferences. Send the important ones, add controls when people complain.
• A settings page full of options. Every option is a decision the user has to make and a branch you have to maintain. Pick sensible defaults.

The timeline conversation

For an agency selling this to a client, or a founder budgeting it, rough shape:

• Weeks 1–2 — scope, data model, and design of the core workflow
• Weeks 3–5 — the foundation layer above
• Weeks 6–9 — the core workflow itself
• Weeks 10–12 — polish, testing, and the things you found

Six to twelve weeks is realistic for a focused MVP. Anything promising four weeks is either building less than you think or skipping the foundation, and skipping the foundation shows up as a rebuild in month five.

Write the scope down

For agencies especially, this is the part that protects you.

A written spec — what's in, what's explicitly out, what happens when it changes — is the difference between a profitable project and a painful one.

Include an explicitly out of scope section. It feels awkward to write and it prevents almost every difficult conversation later. When someone asks for the export feature in week eight, you point at the document rather than negotiate from scratch.

And agree the change process in advance: new requests get a written estimate before work starts. Not a conversation at invoicing time.

Launch before it's ready

The hardest part isn't technical. It's that everyone wants to add one more thing before showing anyone.

Your first version will be embarrassing. That's correct. The purpose of v1 isn't to impress people, it's to find out whether the thing you believe about your customers is true.

Every week you spend polishing before launch is a week you might be polishing the wrong product.

Get it in front of ten real users. Watch where they get stuck. That will tell you more about what to build next than any amount of internal debate.

---

We build SaaS MVPs for agencies and founders, under your brand if you want it that way. See how we scope and ship.