The decisions that get expensive at customer one hundred.
A SaaS product is not an application with a login screen. Tenancy, billing, onboarding and cost per customer are architectural decisions, and every one of them is far cheaper to make correctly at the start than to correct once you have customers.
Four decisions you can only make cheaply once.
Tenancy is the first. Shared database with a tenant column is cheap to run and hard to isolate; a database per tenant isolates cleanly and costs more to operate. Both are defensible, and changing your mind at two hundred customers is a migration project with no business value attached.
Billing is the second. If usage is not metered from the beginning, introducing consumption pricing later means reconstructing history you never recorded.
Onboarding is the third, and the most commonly deferred. A product that needs your team to configure each new customer has a ceiling on growth that no amount of sales effort moves.
Unit economics is the fourth. Knowing what one tenant costs you to serve is what turns pricing from a guess into a decision, and it is nearly impossible to reconstruct after the fact if the infrastructure was never tagged for it.
The layers a product needs before it has customers.
Every one of these is cheap to build early and disruptive to retrofit. The order matters as much as the content.
Three isolation models, chosen against your buyers.
This is usually decided by who you sell to rather than by engineering preference. Enterprise buyers with procurement questionnaires push you up this table quickly.
| Model | When it fits | What it costs |
|---|---|---|
| Shared schema | Self-serve and SMB products where per-tenant volume is modest and buyers do not audit your architecture. | Cheapest to run and easiest to release to. Isolation depends entirely on discipline in every query. |
| Schema or database per tenant | Mid-market and regulated buyers who ask where their data physically sits. | Materially more operational work, migrations, backups and monitoring now multiply by tenant count. |
| Dedicated deployment | Large enterprise or public-sector customers with residency or isolation requirements written into the contract. | The highest cost per tenant, priced accordingly. Only viable with automated provisioning. |
Six things a procurement questionnaire will ask for.
These arrive as a spreadsheet from your first serious enterprise prospect, usually with a deadline. Building them in advance is far cheaper than building them in a fortnight.
Single sign-on
SAML and OIDC against the customer's identity provider. This is the most common single blocker on enterprise deals, and it is not a small retrofit.
Roles and permissions
Granular, customer-configurable roles, not three hard-coded levels that map poorly onto how their organisation is structured.
Audit logging
Who did what, when, exportable. Regulated buyers will ask, and a log you cannot export does not count.
Data export and portability
A complete export in a usable format. Buyers increasingly test the exit before signing the entrance.
Uptime commitments and status
An SLA you can meet, backed by monitoring and a public status page.
Security posture
Penetration test results, a vulnerability process, and a credible path to SOC 2 or ISO 27001 if you do not hold one yet.
A stack that scales without a rewrite at every stage.
SaaS punishes premature complexity as hard as it punishes premature simplicity. We aim for boring, well-understood components with clear seams.
Frontend
Component libraries and design systems that survive rapid iteration.
Backend
Services with clean tenant boundaries and predictable operational cost.
Data
Tenancy-aware schema design, migrations and backup strategy.
Cloud & DevOps
Per-tenant cost attribution and repeatable provisioning.
Mobile
Where the product needs a companion app instead of a responsive site.
AI & ML
Product features that need a model, priced into the unit economics.
Sellable early, scalable by design.
-
Weeks 1–2
Settle the architecture
Tenancy, identity, metering and billing decided and written down before code. You get an architecture decision record you can put in front of a buyer.
-
Weeks 3–5
Build the foundations
Multi-tenant skeleton, authentication, provisioning and pipelines, with tenant isolation demonstrated, not asserted.
-
Weeks 5–14
Build the product
The core workflow in two-week cycles with real users involved throughout, so what gets built is shaped by usage, not by the original plan.
-
Weeks 14–16
Add the commercial layer
Plans, trials, upgrades, invoicing and self-service onboarding; the point at which the product can take a customer without your team touching it.
-
Ongoing
Scale on evidence
Performance, cost per tenant and the enterprise-readiness backlog, driven by the deals actually in front of you.
Before you build a SaaS product.
The three below are the ones this page does not already answer. Anything more specific, put it to us directly.
We have one customer paying for a custom build. Can it become a product?
Sometimes, and it is worth being clear-eyed about which case you are in. A custom system becomes a product when the second and third customers want substantially the same thing; it becomes an expensive maintenance burden when each wants their own variation and you agree to all of them. The technical work is the same either way, extracting tenancy, making configuration data rather than code, and separating what is shared. The commercial discipline is harder: at some point you have to tell a paying customer that their request will not be built. Most single-customer-to-product transitions fail on that conversation rather than on the engineering.
How much should we build before we try to sell it?
Less than instinct suggests. The purpose of the first release is to find out whether people will pay, and a narrow product that does one job properly answers that better than a broad one that does six things adequately. What you cannot skip is the commercial layer (sign-up, billing and onboarding) because a product that requires your team to manually provision every trial cannot generate the signal you are looking for. We would rather ship a small product that can genuinely take a customer than a large one that cannot.
Do we need SOC 2 before we can sell to enterprises?
Not always before the first deal, but usually before the fifth, and the sequencing matters more than the certificate. Many enterprise buyers will accept a security questionnaire, a recent penetration test and a documented roadmap for a first contract, particularly if the data involved is not highly sensitive. What kills deals is discovering mid-procurement that you have no audit log, no SSO and no way to export a customer's data. Build those in early, they are the substance a certification attests to, and they are useful whether or not you pursue one.