SaaS platforms, built around the one decision you cannot reverse cheaply.

Tenancy and the data isolation model

Shared schema with a tenant column, a schema per tenant, or a database per tenant. The choice looks like an infrastructure preference and is actually a commercial one, because it decides which enterprise questions you can answer yes to and how much a regulated customer costs you to serve.

Shared schema is cheapest to run and hardest to defend in a security review, because isolation depends on every query being correct forever. Database per tenant answers the isolation question immediately and turns migrations into a fleet operation. Most platforms should choose deliberately and support one exception rather than drifting into a hybrid nobody designed.

Data residency belongs here too. If you will ever need to keep European data in Europe, the tenancy model has to carry region as a first-class attribute rather than a later migration.

Identity, single sign-on and permissions

Consumer signup and enterprise identity are different products. The first is an email and a password. The second is SAML or OIDC against the customer's own provider, automated user provisioning and deprovisioning, and a permission model their security team will review line by line.

The deprovisioning half is the one teams forget and auditors always check. When an employee leaves the customer's company, their access to your platform has to end without anybody remembering to do it manually.

Permissions should be role-based from the start with resource scoping designed in. Retrofitting granular permissions onto a platform that assumed two roles is close to a rewrite of every authorization check.

Billing, plans and entitlements

Plans are marketing. Entitlements are engineering. The mistake almost every platform makes is scattering plan checks through the codebase, so that changing what a tier includes means finding twenty conditionals and hoping you found them all.

An entitlement service that answers one question - can this tenant do this thing right now - keeps pricing changes out of the release cycle. That matters because pricing changes constantly in this sector, and a platform that needs a deployment to launch a new tier will lose the experiment.

Usage metering is the harder half. If you bill on consumption, the meter is a financial record: it needs to be idempotent, reconcilable and defensible to a customer disputing a number.

API surface, webhooks and integrations

The API is a product with its own lifecycle, and in B2B it is often the reason a deal closes. That means versioning decided before the first external consumer, not after, and a deprecation policy you can actually honour.

Webhooks deserve the same care as ingestion did in other sectors: they will be retried, they will arrive out of order, and a customer whose endpoint was down for an hour will expect replay. Signing them and documenting the retry schedule is the difference between an integration partner and a support ticket.

Rate limits are a product decision as much as a protection: too tight and you break integrations, too loose and one customer degrades everyone.

Security posture and the evidence for it

Enterprise buyers do not ask whether you are secure, they ask you to prove it, and the proof is documentary. Audit logs covering who did what and when, retained long enough to answer a question about last year. Encryption at rest and in transit with the key management described. Access reviews that happened and can be shown to have happened.

We build to the controls those frameworks require and generate the evidence continuously, which turns an audit into an export rather than a project. Where you are pursuing certification we support the process directly, because assembling evidence retrospectively is the expensive way to do it.

Scale, limits and the noisy neighbour

In a multi-tenant platform, one customer's bad afternoon becomes everyone's. A tenant running an unbounded export, an integration retrying in a tight loop, or a genuinely large account doing normal things at ten times the volume will all degrade the platform unless limits exist per tenant rather than globally.

Fair queuing, per-tenant quotas and the ability to isolate a specific tenant onto its own capacity are the tools. The last one is also a commercial feature: the largest customers will pay for dedicated capacity, and a platform that can offer it has a product rather than an exception.

Launch and day two

A design-partner cohort before general availability, because the questions that reshape a SaaS platform come from customers using it rather than from planning. The first enterprise prospect will produce a security questionnaire that is worth more than a quarter of roadmap guessing.

Day two in this sector is about onboarding friction and support load, both of which are measurable from the first week. Sixty days of dedicated support, six months of priority bug resolution, twelve months of updates.