Skip to main content
Free checklist

SaaS MVP Planning Checklist: 9 Decisions to Make Before You Build

By Obaid Tariq, Founder & Lead Engineer · Published

Disclosure: AI Dev Planner builds SaaS products for clients. This checklist is written to be useful whoever builds yours. See our disclosure policy. It is general information, not legal, tax or financial advice.

The short version

A SaaS MVP is ready to build when you can answer nine questions in writing: who has the problem and what is the evidence, which single workflow the first version must handle, what has been cut, how accounts and tenants work, how you will charge, what data you hold and where, which services you depend on, how you will measure the launch, and what it will cost and who will own it.

Work through the checklist below in order; the early decisions shape the later ones. When you are done, turn your answers into a brief with our software requirements document template.

1. Write down the problem and the evidence for it

Before you talk about features, settle who has the problem, how they handle it today, and what evidence says they would pay for a better way.

  • Name one primary customer: a role in a type of organisation (for example, "operations managers at 20 to 200 person logistics firms"), not "small businesses".
  • Describe what they do today instead: the spreadsheet, the competitor, the manual process or the outsourced service.
  • Record the evidence you already have, such as interview notes, a waitlist, letters of intent, pre-orders or paid pilots, and mark which is strongest. Money committed is stronger evidence than interest expressed.
  • Write down the result that would tell you the idea is wrong, before you build anything.
  • Look at two or three competitors: what they charge, who they target and what their users complain about in public reviews.

If the evidence list is empty, the MVP is the experiment rather than the product, and it is cheaper to run that experiment before writing code. You can structure it with interviews, a landing page or the AI Dev Planner validation platform.

2. Define the one workflow the MVP must handle end to end

A SaaS MVP proves that one job can be done better. Write that job as the steps a user takes, from arriving at the product to getting the result they came for.

  • Write the workflow as five to ten plain-language steps, starting with how the user first arrives (an invitation, a sign-up page, a sales demo).
  • Mark the moment the user gets value. That is your activation event, and every step before it is friction to remove.
  • List the screens the workflow needs. As a rule of thumb, if it needs more than a dozen, check whether it is really two workflows.
  • Note everyone else who touches it: an admin who sets things up, an approver, or your customer's own customers.
  • Write down what the user does if something goes wrong at each step, because error and empty states are part of the workflow.

3. Cut the scope into must have, later and not now

Sort every feature idea into three lists and agree them in writing, so the budget goes on the core workflow rather than around it.

  • Must have: without it, a paying user cannot complete the core workflow.
  • Later: useful, but the MVP can launch and be judged without it.
  • Not now: ideas that belong to a different customer, a different product or a much later stage.
  • Common "later" candidates: native mobile apps, a public API, advanced reporting and exports, multiple languages, custom branding per customer, and single sign-on unless your buyers require it to sign.
  • Decide what you will do by hand behind the scenes instead of building it at first, such as onboarding calls, data imports or invoicing annual plans.

This is a simplified form of MoSCoW prioritisation (must, should, could, won’t). The labels matter less than the rule: anything not on the must-have list needs a reason to be built before launch.

4. Decide accounts, tenancy and roles

Most B2B SaaS products serve organisations rather than individuals. Decide the account model now, because it shapes the database and is expensive to change later.

  • Individual accounts, or organisations (workspaces) with members? Can one person belong to several organisations, as consultants and agencies often do?
  • How each customer's data is kept separate: a tenant ID on every row enforced by the database (for example PostgreSQL row level security), a schema per tenant, or a database per tenant. The first is the usual starting point; the others suit stricter isolation requirements.
  • The roles the MVP needs. Owner, admin and member covers many products; a full custom-permission system rarely belongs in an MVP.
  • How people sign in: email and password, magic links, or Google and Microsoft accounts. Note whether your buyers' IT teams will ask for SSO.
  • Invitations, removing a member, transferring ownership, and what happens to a departing member's data.

5. Plan pricing and billing

Decide how you will charge before the build starts, even if the first customers pay by invoice. Billing touches access control, emails and support, not just a checkout page.

  • Pricing model: per seat, per usage, flat tiers or a mix. Write down exactly what each plan unlocks, because that list becomes access rules in the code.
  • Free trial or free plan, what happens when a trial ends, and whether a card is required up front.
  • Payment provider and which events change access: payment succeeded, payment failed, subscription cancelled, plan changed.
  • Treat payment webhooks as messages that can arrive late, twice or out of order. Stripe’s documentation says it does not guarantee that events are delivered in the order they were generated, and that an endpoint might occasionally receive the same event more than once, so the app should record the events it has processed (Stripe Docs, accessed 18 October 2026).
  • Sales tax and VAT for every country you sell into. In the UK, GOV.UK says you must register for VAT if your total taxable turnover for the last 12 months goes over £90,000 (GOV.UK, register for VAT, accessed 18 October 2026). Ask an accountant about the rules for selling digital services abroad.
  • Who handles refunds, failed payments and plan changes in the first months. Often that is a person working from the payment provider's dashboard, not code.

6. Map data, privacy and security

List the data the product will hold, where it will be stored and who can see it. This decides your hosting region, the contracts you need and much of the security work.

  • Will the product hold personal data? Any special category data, such as health information, or data about children? Those raise the bar considerably.
  • Pick a hosting region your customers will accept, such as the UK, EU or US, and say so in your privacy policy.
  • If a supplier, including a development company, will process personal data on your behalf, you need a written contract with them. The ICO says that every time a controller uses a processor to process personal data, there must be a written contract (ICO, accessed 18 October 2026). Similar rules apply under the EU GDPR.
  • Secrets such as API keys and database credentials live in server-side configuration, never in client code or the repository.
  • Automated backups, and a restore you have actually tested once before launch.
  • The questions your first business customers' security teams will send: access logging, data deletion on request, encryption in transit and at rest, and who on your side can reach production.

7. List integrations and third-party services

Every integration is a dependency with its own limits, costs and failure modes. List them now so they can be estimated rather than discovered halfway through the build.

  • Infrastructure services almost every SaaS needs: transactional email, file storage, error monitoring, product analytics and payments.
  • Customer-side integrations, such as a CRM, accounting software, calendars or Slack. Include only the ones the core workflow cannot work without.
  • For each one: is there a documented API, what will it cost at your expected volume, and what should the product do when that service is down?
  • For AI features: which model provider, what data is sent to it, whether that data may be used for training under the provider's terms, and a monthly usage budget.

8. Decide how you will launch and measure

Agree what success looks like for the first users, and make sure the product can tell you whether it is happening.

  • One activation metric, for example "created a first project and invited a colleague within seven days", and one retention signal, such as weekly active organisations.
  • The analytics events needed to measure them, named and agreed before the build so they are not bolted on afterwards.
  • Error monitoring and uptime alerts working on launch day, with a named person who receives them.
  • A support route, such as a shared inbox or chat, and who answers it in the first weeks.
  • Legal pages: privacy policy, terms of service and, where you use non-essential cookies, a consent notice.
  • A named list of the first users you will onboard personally, and how you will collect their feedback.

9. Set the budget, timeline and ownership

Turn the scope into a budget range, agree how the build will run, and make sure your company owns what it pays for.

  • Get an indicative range from the MVP cost calculator before talking to suppliers, then compare quotes against the same written scope.
  • Hold a contingency for the unknowns you listed in the sections above, agreed in advance rather than discovered.
  • Fix the launch scope rather than the launch date where you can; when the date is fixed, agree in advance which "must haves" can move to "later".
  • Decide who builds it. Our guide to agency vs freelancer vs in-house developers compares the options, and how to choose a software development company covers the questions and contract clauses to check.
  • Ownership: the code in a repository your company owns from day one, hosting and third-party accounts in your company's name, and a written IP assignment in the contract.
  • A budget for after launch: hosting, third-party services, maintenance and the next round of improvements.

Common SaaS MVP planning mistakes

  • Building the admin side and settings screens before the customer-facing workflow works.
  • Designing an enterprise permission system before there is a single enterprise customer.
  • Leaving billing until after launch, then retrofitting access rules into every screen.
  • Building a native mobile app and a web app at the same time for the first version.
  • Counting sign-ups instead of activation, so a launch looks successful when nobody reached the point of value.
  • Choosing a technology stack nobody available to you can maintain once the first team moves on.

If you want help with the build

AI Dev Planner is a software development company with an engineering team in Islamabad, Pakistan, working remotely with clients worldwide; we do not have a UK office. We build SaaS MVPs on the decisions in this checklist, starting with a discovery phase that turns your answers into a scoped plan. If you have not yet tested whether anyone wants the product, we will suggest doing that first.

SaaS MVP planning FAQs

What should a SaaS MVP include?

The smallest product a paying customer can use to complete one core workflow end to end: sign-up or invitation, the workflow itself, the account and role model it needs, a way to pay (even if that is an invoice at first), and the analytics to tell you whether users reach the point of value. Everything else belongs on a "later" list until the MVP shows it is needed.

Should a SaaS MVP be multi-tenant from day one?

If you sell to organisations, usually yes in the data model: give every record an organisation (tenant) and enforce the separation in the database from the start, even if each customer begins with one user. Retrofitting tenancy onto a single-user data model touches almost every table and query. What you can postpone is the complexity around it, such as custom roles, single sign-on and per-customer configuration.

How long should SaaS MVP planning take?

Long enough to answer every section of this checklist in writing, which for a focused product is usually days or a few weeks of founder time rather than months, followed by a discovery phase with whoever will build it. If planning keeps growing, the scope is usually too large or the evidence too thin, and the answer is to cut scope rather than plan harder.

How much does a SaaS MVP cost?

It depends on the scope this checklist produces, especially the number of roles, integrations and billing rules. Our own published planning range for a SaaS or web-app MVP is £25,000 to £45,000 (GBP), with 8 to 12 weeks for a focused SaaS MVP. Use the MVP cost calculator for an indicative range for your product, and compare every quote against the same written scope.

Do I need a technical co-founder to plan a SaaS MVP?

Not to plan it. Most of this checklist is about customers, scope and commercial decisions that a founder should own. For the technical sections, such as tenancy, hosting region and integrations, ask whoever will build the product to explain the options and trade-offs in writing, so you can make the decision rather than inherit it.

Sources

  1. Stripe Docs: Receive Stripe events in your webhook endpoint — Stripe does not guarantee event order, and endpoints may occasionally receive the same event more than once. Accessed 18 October 2026.
  2. GOV.UK: Register for VAT (UK) — UK VAT registration is required once taxable turnover for the last 12 months goes over £90,000. Accessed 18 October 2026.
  3. ICO: When is a contract needed and why is it important? (UK) — A written contract is required every time a controller uses a processor to process personal data. Accessed 18 October 2026.

Finished the checklist?

Send us your answers. We will tell you what we would cut, what we would build first, and whether we are the right team for it.

Send us your plan Estimate your MVP cost