The difference between a single-customer system and a SaaS product is not in the screens — the same screens can serve both. The difference is underneath: who sees what, who pays for what, and what happens when the payment fails. This scope document goes through the definitions to close before development starts, in the order they depend on each other. It is not a code guide and not a pricing guide — it is the list of decisions without which a SaaS development quote prices a different product from the one you will need.
Customer, user and subscription — three entities, not one
The most common mistake in a first SaaS definition is thinking of "the user" as the one who signs up, uses and pays. In a product sold to businesses these are three separate entities, each with its own lifecycle:
| Entity | What it is | What belongs to it | Example |
|---|---|---|---|
| Customer (account / tenant) | The body that buys the service and owns the data | The data, the settings, the plan, the payment method, the invoices | An accounting firm with 12 employees |
| User | A person who signs in and acts inside a customer, with a role | Identity, role, preferences, action history | An accountant at the firm; the office manager; an intern with view access |
| Subscription | The commercial agreement between the customer and the product, at a given time | Plan, billing cycle, state (trial, active, past due…), start and end dates | "Office" plan, annual billing, active until 31 Dec |
Core capabilities: authentication, tenant separation, permissions and billing
The following four capabilities are what turn a set of screens into a product you can sell to several customers. Each is a decision that needs a written answer before development, because all of them sit at the base of the system, not in a layer you can swap:
| Capability | Decisions to make | What happens if the decision is deferred |
|---|---|---|
| Authentication | Password, one-time code, sign-in via Google/Microsoft, or the customer's organisational SSO? Two-factor mandatory for whom? How is a user invited into a customer? | The first large business customer will demand SSO; adding it retroactively touches every sign-in screen and the user model |
| Tenant separation | All customers in one database with a customer id on every record, or a separate database per customer? How is every query guaranteed to be filtered? What about files, search and reports? | This is the one decision that cannot be fixed without a rebuild; a leak between customers is the end of the product |
| Permissions | Which roles exist inside a customer (owner, admin, user, viewer)? Who creates roles — you or the customer? Are there record-level permissions? Who on your side can see customer data for support, and how is that logged? | Without a permission model, every customer request that "the intern must not see payroll" is new development |
| Plans and billing | Which plans, and what each one allows (users, records, features)? Monthly, annual, per-user or usage-based billing? Through a payment provider or a manual invoice? Who issues the tax invoice? | A plan not enforced in code is a plan that does not exist; manual billing does not scale past a few dozen customers |
Add support to these — not as a feature but as a process: how a customer reports a problem, who on your side sees what in order to handle it, and how access to customer data is logged. In a product sold to businesses, a customer will ask about this before signing.
Upgrade, cancellation and payment failure: the subscription lifecycle as a state table
Most SaaS logic is not in the "active" state — it is in the transitions. The table below is an original state diagram written for this document: for each state, what users see, what the system does, and where it can move. It is a starting point — your product will add or remove states — but every row in it needs an answer before development.
| State | How it is entered | What users see | What the system does | Where it moves |
|---|---|---|---|---|
| Trial | A new customer signs up | The full product or a limited plan, with days remaining | Schedules reminders; blocks capabilities outside the plan | Active (payment method added) · Expired (not added) |
| Active | First payment succeeded, or a renewal succeeded | The product per the plan | Charges per cycle; enforces plan limits; issues an invoice | Plan change · Scheduled cancellation · Past due (charge failed) |
| Plan change (upgrade / downgrade) | The customer chose another plan | Upgrade: capabilities immediately. Downgrade: capabilities until period end, plus a warning if the new limit is exceeded | Calculates a pro-rated charge or defers to renewal; checks that existing data fits the new plan (15 users on a 10-user plan, for example) | Active (on the new plan) |
| Past due (payment failure) | A recurring charge failed | An in-product notice; the product keeps working during a grace period | Retries per policy (3 attempts in two weeks, for example); sends notices; logs every attempt | Active (charge succeeded) · Suspended (all attempts failed) |
| Suspended | The grace period ended without payment | Access to a payment screen only; data is neither deleted nor accessible | Blocks access; retains data for a defined period; warns before deletion | Active (paid) · Cancelled (retention period passed) |
| Scheduled cancellation | The customer asked to cancel | The product works until the end of the paid period; option to undo; data export available | Stops future charges; records the end date; offers export | Active (cancellation undone) · Cancelled (end date reached) |
| Cancelled | The end date arrived, or the retention period after suspension ended | No access; a notice about data deletion and its date | Deletes or anonymises data per policy and agreement; keeps billing records as the law requires | Trial / Active (the customer returned — a new customer or a restore?) |
Every transition in the table has a test that must pass before launch: a mid-period upgrade charges correctly; a downgrade with data above the limit deletes nothing without confirmation; a failed payment does not block immediately; a cancellation does not delete immediately; and a suspended customer who pays gets all their data back. These are the acceptance scenarios of a SaaS — not just "the screen opens".
What belongs in a first commercial version?
A first SaaS version faces a double pressure: it must be small to ship, but a few things in it cannot be deferred because they sit at the base. The split below separates what must be built right from the start, what can be manual at first, and what can be deferred:
| Must be built right from the start | Can be manual at first | Can be deferred |
|---|---|---|
| Tenant separation in every layer — data, files, search, reports | Creating a new customer (you set it up instead of self sign-up) | Multiple plans — start with one or two |
| The customer–user–subscription model, even if its admin screens are simple | Billing — a manual invoice for the first few dozen customers, as long as the subscription state is recorded in the system | Self-managed roles by the customer — two or three fixed roles at first |
| Secure authentication and inviting users into a customer | Plan change — done by you on request, not at the click of a button | Organisational SSO — until a paying customer demands it |
| Action logging (who did what, when) — at least on commercial actions and deletions | Support — a mailbox and a person, not a ticketing system | Full payment-failure automation — as long as there is a documented manual process |
| Backup and restore that were actually tested | Customer reports — a file export before a dashboard | A customer API, integrations, a marketplace |
How to prioritise the rest of the scope — the product screens themselves — in a first version, in a separate MVP scope guide. The logic there applies here too, plus the first column in the table above, which in SaaS is not negotiable. How to define the scope of an MVP
Delivery and operations conditions: backup, support, monitoring and usage costs
A SaaS product is not delivered — it is operated. On launch day an ongoing commitment to paying customers begins, so the "delivery" of a SaaS also includes what makes it operable. These are the conditions that should be defined and built before the first paying customer:
- Backup and restore: how often you back up, how long you keep it, and whether restoring one customer (not the whole system) was actually tested. A business customer will ask "what if we deleted something by mistake" — there should be a demonstrated answer.
- Monitoring and alerts: who knows the system is down before the customer calls, and what they do. Both availability and business errors — failed charges, unsent notices.
- Support: channel, hours, a response time you are willing to write into the agreement, and what a support person may see and do inside customer data — and how that is logged.
- Releases: how a new version goes live without dropping customers mid-work, and how changes that affect them are announced.
- Usage costs: hosting and database that grow with data, a payment provider taking a percentage of each transaction, email/SMS services by volume, and third-party services by calls. The structure is known in advance; the values depend on assumptions about customer count and usage, so they do not appear here.
What it costs to keep a live product running over time — maintenance, updates, infrastructure — and how to budget for it, in a separate guide on maintenance costs. What it costs to maintain a product after launch
Marked example: a parking-management product
What we do at this stage
When a system has to serve several separate customers, we start by mapping exactly the five definitions in this document — customer/user/subscription, separation, permissions, plans and billing, operating conditions — before talking about screens. The output is a scope document that separates what is built right from the start, what is manual at first and what is deferred. What changes in a system when it serves several customers, and how that fits into our software development service — in the dedicated section on the service page. Software development — when the system serves several customers
And if the product is still before its first paying customer, its first version is an MVP — with the first column of the table above included. This is how we define and build a first version. MVP development — how a first version is defined and built