Your first SaaS: the tenant questions that are expensive to fix later

In a SaaS product, many customers share one system. Each customer is a tenant, and the cardinal rule is that no tenant should ever see another tenant's data. That rule is simple to say, and it shapes the database, the login, the billing and the support tooling. Fixing it after launch usually means rewriting the parts that touch customer data, which is most of the product.

The five questions below are worth settling before the first customer signs up.

1. Where does the tenant boundary live?

Every record needs a clear tenant. The common options are one database per tenant, one schema per tenant, or one shared database with a tenant identifier on every row. Separate databases give strong isolation and higher running cost. A shared database is cheaper and needs discipline: every query must filter by tenant, every time. AWS's SaaS Lens for the Well-Architected Framework is written for exactly this kind of design decision, and its abstract describes helping teams understand the business impact of their design choices.

2. How will you stop one customer seeing another's data?

OWASP's Multi-Tenant Security Cheat Sheet lists the failure modes: cross-tenant data leakage, tenant impersonation, broken isolation at the database, cache or storage layer, and manipulated tenant identifiers in requests or tokens. Ask your builder how each is prevented, and ask for a test that tries to cross the line on purpose.

3. What happens when one customer is loud?

The same cheat sheet names noisy neighbors: one tenant using so much of a shared resource that others suffer. A customer importing a million rows should not slow down everyone else's morning. Decide on limits, queues and per-tenant usage tracking now, even if the limits are generous.

4. How does a new customer get started?

Onboarding is where a SaaS product wins or loses its first week. Can a customer sign up, invite their colleagues, set up their data and see value without a call? If not, what is the least you can do by hand for the first ten customers while you learn what to automate? Be honest about which steps are manual, and keep a list.

5. How will you charge, and what will you measure?

Decide whether you charge per user, per usage or per plan, and record the usage you will need to bill that way from day one. It is much harder to add metering later than to collect it early and decide what to do with it afterwards. Track the basics per tenant: sign-up date, active users, the main action your product exists for, and support requests.

Keep the first version small

You do not need a full enterprise setup for ten customers. You do need the decisions above made on purpose, written down, and tested. A small product with a clear tenant boundary is easier to grow than a large one that has to be rebuilt.

If you are weighing whether to build a product at all, start with internal tool or SaaS product. If you already know, talk to us about web apps and we will help you scope the first release.