A SaaS MVP scope checklist for production: must-have vs phase-two for auth, billing, admin, email, and monitoring so founders ship one complete job. I use this checklist when scoping fixed-price builds so “MVP” means production-ready, not half-finished.
Short answer
A production saas mvp scope checklist includes auth and roles, one complete core workflow, billing with webhooks, thin admin, transactional email, deploy, and monitoring. Phase two holds SSO, mobile apps, public APIs, and platform fantasies. If a feature does not help a real user finish the job or help you operate the product, it is not MVP.
Define “production MVP” before you write tickets
Production means a stranger can sign up, complete the job, pay or start a trial, and you can support them without SSH. Prototype means friends can click through a happy path on localhost.
Founders blur those definitions and then feel cheated when a “two week MVP” cannot take money. Write the definition into the scope document first.
Must-have vs phase-two checklist
| Area | Must-have in MVP | Phase two |
|---|---|---|
| Auth | Email/social sign-up, reset, org + invite, 2 roles | SSO, SCIM, passkeys everywhere, fine-grained ACLs |
| Core product | One job: list, detail, create/edit, one export/share | Second product line, automation suites, marketplace liquidity |
| Billing | 1-2 plans, trial, portal, webhook entitlements | Metered usage, multi-currency, custom enterprise invoices |
| Admin | Users/orgs, plan status, ban/pause | Full CRM, BI warehouse, custom report builder |
| Welcome, invite, receipt, failed payment | Lifecycle marketing, complex drip campaigns | |
| Ops | Prod + preview, error tracking, basic analytics | Multi-region, advanced observability, chaos drills |
Auth: enough trust to start, not a security thesis
Ship sign-up, login, password reset, organisation creation, and invite-a-teammate with owner and member roles. Session security, HttpOnly cookies or well-handled tokens, and locked-down secrets are part of “done,” not extras.
Skip building your own crypto. Use a proven auth approach and document how roles attach to organisations. Acceptance checks worth writing down: invite email arrives, accepting invite joins the correct org, members cannot delete the org, owners can remove members, logged-out users cannot hit protected routes.
If you need social login, pick one provider for v1. Supporting five identity providers before anyone pays is a hobby, not a scope. Deep dive: Node.js authentication best practices.
Core workflow: name the job in one sentence
Examples from shipped work:
- Invito: create a personalized invite and deliver it (including bulk paths where that is the product)
- RBX Earner: complete offers and redeem rewards with clear status
- RenderMyJewelry: upload CAD and receive a trustworthy visual output
- Tapiloo / studio clients: one operational job the buyer already pays someone to do manually
Your scope should list screens and states for that job only: empty, loading, success, validation error, permission denied. Edge-case sprawl is how checklists become novels.
Write three user stories max for v1, not thirty. If a story does not help the one-sentence job, it is phase two. Also list the data entities (User, Org, Job, Subscription) so engineering and product share a vocabulary before tickets multiply.
Billing: entitlements are the product boundary
Include Checkout or equivalent, customer portal, trial rules, and webhook handlers that update plan status idempotently. The success redirect is a UX nicety. The webhook is the ledger.
Write plan names and limits into the scope (seats, exports, renders). Ambiguous “Pro gets more” becomes a dispute. Include failed-payment behavior: does the user keep read-only access for three days, or lose export immediately? That sentence prevents angry support threads.
Test-mode rehearsal belongs in the checklist: upgrade, downgrade, cancel, fail a card, confirm UI and permissions match. Details: Stripe + Node.js subscriptions.
Admin: operate week one without a database GUI
Minimum admin surfaces:
- Search users and organisations
- See subscription status and last payment event
- Disable or pause abusive accounts
- Trigger a password reset or resend invite when support needs it
You can style admin plainly. Ugly admin that works beats a beautiful vacuum. If your product involves payouts, offer walls, or user-generated storefronts (RBX-shaped work), add a moderation queue early. Trust ops is part of the product, not a later surprise.
Gate admin behind a strong role check. An open /admin route is how “MVP speed” becomes an incident report.
Email and deliverability
Transactional email is in scope: welcome, invite, receipt, failed payment. Configure SPF/DKIM on your domain. Use a real provider. “We will use console.log for invites” is not production.
Marketing newsletters are phase two unless the product is email. Mixing lifecycle marketing into MVP scope is a classic delay tactic.
Include a simple email template style that matches your product enough not to look like phishing. Perfect brand systems can wait. Readable subject lines and correct links cannot.
Monitoring, analytics, and legal pages
Ship with error monitoring (you need stack traces on day one), a basic product analytics path for the core job, and privacy/terms pages linked from sign-up. Uptime robots or equivalent heartbeats take an hour and save panic.
Do not require a full data warehouse. Do require that someone gets paged or emailed when the app 500s after deploy. Track at least: sign-ups, core job completions, checkout starts, and checkout successes. Those four numbers tell you if the MVP is alive.
Acceptance criteria template (copy into the SOW)
For each must-have area, add two or three testable lines:
- Auth: “Owner can invite a member who gains access within one minute of accepting.”
- Core: “New user completes the job on mobile Chrome without admin intervention.”
- Billing: “Failed payment webhook removes paid entitlement within five minutes in test mode.”
- Admin: “Support can find a user by email and pause the org.”
- Ops: “A forced 500 appears in error monitoring within two minutes.”
If a vendor refuses acceptance criteria, they are selling effort, not outcomes.
Explicit out-of-scope protects both sides
Paste a blunt list into the contract:
- Native iOS/Android apps
- Public developer API
- SSO / SAML
- AI features without a measured job
- Second marketing site redesign
- Migrations from legacy systems not listed
When a stakeholder asks for one of these mid-build, you have a change request, not an argument. Keep a living phase-two doc so good ideas are captured without derailing the sprint. Capture is free. Building is not.
Sequencing the build without fake parallelism
A sane order for most SaaS MVPs: data model and auth, core workflow on preview, billing entitlements, admin and email, then monitoring and launch hardening. Designing the marketing homepage in parallel is fine. Building a second product module in parallel is how both modules ship half-broken.
Resist the urge to polish empty states for screens that are not in the must-have table. Empty-state poetry is cheap dopamine and expensive calendar time when billing still fails on webhook retries.
If design and engineering disagree mid-build, the written acceptance lines win. Update the lines deliberately through a change request if the product insight is real. Do not silently reinterpret them in Figma comments.
How this maps to studio delivery
On zaneone.one/portfolio, the products that launched cleanly shared this checklist discipline. Heavier subsystems (3D pipelines, bulk editors, offer walls) were priced as first-class scope, not smuggled under “MVP polish.” Architecture notes that keep full-stack delivery sane: Next.js full-stack SaaS patterns and the hiring companion Next.js SaaS MVP hiring checklist.
When founders arrive with a forty-item wishlist, we rewrite it into this checklist first. The rewrite is the product decision. Coding before that rewrite is how budgets evaporate.
FAQ
What should a production SaaS MVP include?
Include authentication with basic roles, one end-to-end core workflow, Stripe (or equivalent) subscriptions with webhook-driven entitlements, a thin admin view, transactional email, production deploy, and basic error monitoring. Everything else is phase two until users prove demand.
What can wait until phase two of an MVP?
SSO, native mobile apps, public APIs, multi-currency, complex RBAC matrices, AI features without a job story, second products, and full design-system rewrites can wait. Keep phase two written so it does not leak into the MVP sprint.
Do I need admin tools in the first MVP?
Yes, at least a thin admin: find users or organisations, see plan status, and pause bad actors. Without it, founders become unpaid support engineers inside the database during the most fragile week of launch.
Is a marketing site part of MVP scope?
A simple landing page with pricing and legal pages is enough. A full brand redesign, blog platform, or multi-locale marketing stack should be a separate workstream so it cannot stall auth and billing.
Next step
Copy the must-have table into your brief, delete anything that does not serve the one user job, and get sign-off before build week one. For a scoped build against this checklist, use contact or review services.
Want this built for your product? Start a project with Zane, or explore shipped work, services, and more guides.