There is a short window early in a SaaS product where a handful of decisions are almost free. Nothing is in production, no customer data exists, and no integration depends on the current shape of anything. A few months later, each of those same decisions carries a migration, a communications plan and a risk register.
This is not an argument for designing everything up front. It is an argument for knowing which small set of decisions has an asymmetric cost profile — cheap now, expensive later — and making those deliberately while the rest stays flexible.
1. Tenancy and isolation
Decide how customer data is separated and be honest about why. Shared-schema is operationally simplest and hardest to walk back. Database-per-tenant is straightforward to explain to a security reviewer and considerably more work to operate at volume. The right answer depends on what your market actually requires, not on what sounds most rigorous.
Whatever you choose, ensure every query path is tenant-scoped by construction rather than by discipline. A tenant filter that developers must remember to apply is a data-leak incident with a delay on it.
2. Identity, and the difference between users and accounts
A person may belong to more than one customer organisation. An organisation may be a subsidiary of another. A user may need to be deactivated in one place and remain active elsewhere. Modelling identity as a flat list of users with a company column is the single most common foundation mistake in B2B SaaS.
- Separate the person from their membership of an organisation.
- Plan for single sign-on before an enterprise customer requires it — retrofitting SSO usually touches session handling, provisioning and support tooling at once.
- Decide how invitations, deactivation and re-activation behave, including what happens to the work someone left behind.
3. Authorisation model
Roles are a presentation of permissions, not a substitute for them. Products that hard-code behaviour against role names accumulate special cases quickly, because real customers always want a role you did not anticipate. Define granular permissions, compose them into named roles, and let the interface talk about roles while the code checks permissions.
4. Entitlements, separate from billing
What a customer is allowed to do and what they are charged are related but not identical. Keeping entitlements separate from the billing system lets you change packaging, run trials, grandfather early customers and grant exceptions without a migration or a deployment.
5. Data lifecycle and export
Decide early what deletion means, because it is nearly impossible to retrofit. Soft delete and hard delete have different obligations, and backups complicate both. Decide retention windows, what a customer can export and in what format, and what happens to their data when they leave.
6. Auditability
In any product touching money, health, or administrative authority, someone will eventually ask who changed a record and when. Application logs are not an audit trail: they are unstructured, rotated, and usually missing the business context. Decide which events are audit events and record them deliberately, with the actor, the subject, the before-and-after state, and the reason where one applies.
7. Observability from the first release
Instrumenting a system you already cannot explain is much harder than instrumenting one you are building. Establish structured logging with consistent identifiers, tracing across service boundaries, and a small set of service-level objectives tied to behaviour a customer would notice.
8. Integration and API posture
Decide whether your API is a product or an implementation detail. If partners or customers will build against it, it needs versioning, documentation, error semantics, rate limiting and a deprecation policy from the start. Adding those to an interface people already depend on is a negotiation rather than a task.
9. Environments and release path
Decide how a change reaches production and how it comes back. Small changes, automated verification, progressive rollout and a rehearsed rollback are worth more than any amount of pre-release ceremony. Enterprise customers will also ask for a sandbox — knowing whether you intend to offer one changes your environment design.
10. The security questions you will be asked
At some point a prospect will send a security questionnaire. Knowing in advance how you would answer questions about encryption, access control, secret management, dependency scanning, logging, backup and incident response tends to improve the architecture — not because the questionnaire is wise, but because it forces specificity.
What this checklist is not
It is not a mandate to build all of this before launch. Several items can be a documented position and a small amount of scaffolding. The point is to avoid discovering in month eighteen that a default chosen in week two now sits underneath every customer you have.
“Make the important choices before they become expensive.”