GUIDE · SAAS · SCOPE
What do you need to define in a SaaS system before development starts?
The product screens are the visible part. What turns them into a product you can sell to several customers at once is the layer underneath — the one most first definitions skip.
Onezero LabsUpdated 13 min read
| Definition | The question | Why before, not after |
|---|---|---|
| Customer · user · subscription | Who pays, who uses, and what links them? | Three distinct entities; mixing them stays in the data model forever |
| Tenant separation | How does customer A never see a record of customer B? | An architectural decision; changing it after launch is a rebuild |
| Permissions | Which roles exist inside a customer, and who manages them — you or the customer? | Determines admin screens, support and liability |
| Plans and billing | What each plan allows, how you charge, and what happens in each subscription state? | The failure states (failed payment, mid-period cancellation) are most of the logic |
| Operating conditions | What do you commit to for a paying customer — backup, availability, support? | A business customer will ask before signing; the answer has to be built, not promised |
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 organizational 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) · Canceled (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) · Canceled (end date reached) |
| Canceled | The end date arrived, or the retention period after suspension ended | No access; a notice about data deletion and its date | Deletes or anonymizes 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 | Organizational 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 prioritize 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 MVPDelivery 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 launchMarked 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 customersAnd 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 builtFAQ
Frequently asked questions
Four base capabilities you do not see in the product: authentication and inviting users into a customer; data separation between customers in every layer (data, files, search, reports); a permission model inside each customer; and plans and billing including every subscription state — trial, active, plan change, payment failure, suspension, cancellation. Plus operating conditions: backup and restore, monitoring, support and releases. These are most of the work in SaaS development, and most sit at the base of the system and cannot be added later without a rebuild.
The customer (account, tenant) is the body that buys the service and owns the data — a company, for example. The user is a person who signs in and acts inside the customer, with a role — a manager or an employee of that company. The subscription is the commercial agreement between the customer and the product — plan, billing cycle and state. One user can belong to several customers, and one customer can go through several subscriptions over time. If the model does not separate the three from day one, it breaks at the first sale that requires it.
No. The service model can be a monthly or annual subscription, per-user pricing, usage-based pricing (records, calls, transactions), or a license with maintenance fees. What defines SaaS is that customers share one system you operate, with their data separated. The commercial model is chosen by how your customers are used to buying — and it affects the subscription state table, not the need for one.
It should be defined before development, because it is a state, not a fault. The usual approach: the subscription moves to "past due" with a grace period in which the product keeps working, the system retries the charge per policy and sends notices; if every attempt fails — suspension, where access is blocked but data is kept for a defined period; and only after that cancellation and deletion per the agreement. The length of the periods and the number of attempts are your commercial decision; what must be built are the transitions, the notices and the data retention.
What sits at the base and cannot be added later: tenant separation in every layer, the customer–user–subscription model, secure authentication, action logging on commercial actions and deletions, and tested backup and restore. What can be manual at first: customer set-up, invoice billing, plan changes on request, email support. What is deferred: multiple plans, self-managed roles, SSO, full payment-failure automation, an API and integrations.
Sometimes, and it depends mainly on one thing: whether the data is already separated by customer. If every table carries a customer id and every query is filtered by it — the move is an addition of a subscription model, permissions and billing. If the system was built on the assumption of one customer — separating the data touches every query, every file and every report, and that is usually close to rebuilding the bottom layer. Checking this is the first step before any decision.
Keep reading
- ServiceSoftware DevelopmentSystems, backend, architecture. Code that lasts.
- GuideBudgeting a web system: what do you define before asking for a quote?The price of a business system is not set by the number of screens. It is set by who uses it, what it replaces, and what it connects to.
- Case studyOneAI — Five years together. All the way to acquisition.A conversational AI platform that developed language intelligence, AI agents and autonomous voice technology for businesses — acquired by monday.com in 2026.
Let's talk
Got a project to scope?
One conversation. You leave knowing what the first version needs to contain and what it will take to build it.
Straight. To the point. On time.