SaaS & MVP
Almost every SaaS project we start in discovery has the same tension: the product owner wants "everything" in v1, and engineering knows every extra module extends time to first real user feedback.
Here's how we typically cut scope — not as a rigid checklist, but as the decisions that keep an MVP focused enough to learn something.
TL;DR
Key takeaways
- v1 should solve one core problem for one primary user type — the rest is distraction.
- Auth, a basic data model, and one payment or onboarding flow typically belong.
- Admin panels, advanced RBAC, webhooks, and white-label often wait until after first paying customers.
- Multi-tenant isolation should be designed in from the start — even if you only have one tenant in v1.
Why scope creeps — and how to stop it
Scope creeps because "just a small admin page" is rarely small, and because stakeholders compare to mature products users already know. An MVP should be embarrassingly simple on features — and sharp on the one flow that proves value.
We write scope as user stories with acceptance criteria and an explicit "not in v1" list. That list is as important as the backlog. Without it you end up with a half-finished product trying to be everything.
Five questions that clarify v1 scope
Run through them in discovery — the answers become your scope contract.
- 01
Who is the first user — and what must they be able to finish?
One primary job-to-be-done. If you have three equally important user types, you don't have an MVP yet — you have three half products.
- 02
How will you know someone got value?
Define one measurable signal: signup that completes onboarding, first export, first payment. Build only what leads there.
- 03
What's the minimum for auth and data?
Typically: login, basic profile, tenant scoping in the database. Not: SSO, custom roles, audit log — unless compliance requires it from day one.
- 04
Does v1 need payment?
If yes: one plan, Stripe Checkout, webhook that activates access. Not: invoicing, metered billing, coupons, and self-serve downgrade in the first release.
- 05
What do you deliberately say no to?
Write it down. "No API in v1", "no mobile app", "no Excel import". That's your defence against scope that comes back as "it only takes a day".
Questions we get over and over
Do we need an admin panel in v1?
Only if internal users can't manage with database tools or a temporary internal page. A full admin UI often eats weeks. Ask: can we support the first ten customers without it?
What about API and webhooks?
Add when a paying customer or integration requires it — not because "every SaaS has an API". v1 can be UI-only if that's the flow you're validating.
Can we skip payments in v1?
Yes, if you manually onboard pilot customers and learn from feedback before taking payment. But if the hypothesis is "people will pay for this", payment belongs in v1 — otherwise you only prove engagement, not willingness to pay.
How many features is too many?
If you can't demo the core flow in under five minutes, scope is too big. Cut until you can — or split into phases with named releases, so you still ship something early.
Mid scope discussion?
Let's cut v1 so it can ship — and still teach you something.
We help prioritise what belongs in the first release and what deliberately waits. Honestly — even if that means fewer features than you hoped.