A SaaS product is tenancy, permissions, and a release you can operate
SaaS is software sold to many customers from one codebase, with isolation, roles, configuration, and a way to ship without taking everyone down. We design that architecture and the first version you can actually sell: the workflow that justifies a subscription, the admin that does not leak tenants, and the billing and audit hooks your finance and security conversations will demand. A weekend prototype is not a multi-tenant platform.
What has to be true for something to be SaaS
Tenancy is a data and identity problem before it is a UI theme. Rows need a tenant key (or a stronger isolation model), authentication must not allow IDOR-style hops between customers, and background jobs must carry tenant context. If those are missing, you have a single-tenant app with extra logins.
Problems this solution is built to address
- An internal tool people now want to buy
The domain works. Isolation, packaging, onboarding and terms do not. That is a productization problem, not a visual refresh.
- A prototype that stored everyone in one table
It demos. It cannot pass a basic security conversation. Tenancy has to be redesigned, not patched with a client_id hope.
- Plan chaos
Sales promises features that the app cannot gate. Entitlements need to be data, not Slack messages to engineering.
- No path to ship weekly
Every change is a fear event. You need environments, migrations and a release checklist.
- Integrations as one-offs
Each customer gets a unique snowflake. Webhooks, API keys and audit belong in the product.
- Empty-tenant syndrome
New accounts land on a blank app. Onboarding and sample data are product work, not a help article.
What we typically design
- Identity and tenancy
Sign-up, invites, SSO later if needed, tenant isolation model, and admin vs member roles.
- Core workflow
The job that earns the subscription, including empty and error states.
- Billing and entitlements
Plan objects, limits, and a hook to the payment provider you choose, without claiming we are a payments company.
- APIs and webhooks
Customer-facing API, event delivery, and versioning discipline so you do not break integrators.
- Observability and audit
Who did what, plus enough logs to debug a tenant without reading another tenant’s data.
- Web and optional mobile clients
Usually web first. Mobile when the job is actually mobile.
Use cases
- Vertical B2B products
A workflow unique to an industry, education ops, professional services, commerce tools, sold as software.
- Startup first product
MVP tenancy that is honest, even if billing is manual for ten customers.
- Platform plus agents
A product that later adds an AI agent per tenant, with tool scopes that cannot jump tenants.
- Add-on to a services firm
Productizing delivery so clients log in instead of living in email, without pretending you are a public cloud overnight.
How a SaaS build runs
- Discovery
Buyer, job-to-be-done, isolation needs, compliance constraints, and whether a existing platform should be used instead.
- Scope the first sellable version
One persona, one workflow, explicit non-goals (marketplace, white-label, every integration).
- Architecture
Tenancy model, auth, data stores, file isolation, background jobs, and how you will migrate.
- Build and review
Two-tenant tests in staging: can A see B? Ship the workflow, then entitlements, then polish.
- Launch and operate
You own the accounts. Handover includes how to add a tenant, how to restore, and how to ship. Iterate on actual usage.
Name the job a paying tenant must complete
Send the buyer, the isolation needs, and whether billing must be in v1. We will tell you if this is SaaS, a single-tenant build, or a product you should buy.