The difference between an agency that builds SaaS products and one that has operated them shows up in three places: how they handle tenancy, how they handle billing, and what they assume about who runs the thing after launch. A vendor strong on features and weak on those three delivers something that demos well and becomes expensive around the first enterprise customer.
01Tenancy is a decision you make once
Shared-schema multi-tenancy with a tenant identifier on every row is the cheapest to run and the hardest to walk back if an enterprise customer demands their data be physically separate. Database-per-tenant isolates cleanly and multiplies operational cost, particularly around schema migrations across hundreds of databases.
The question to ask a prospective partner is not which model they prefer, but what happens when a large customer requires isolation the chosen model does not provide. A vendor who has operated SaaS has a migration path; one who has not treats the question as hypothetical.
| Model | Isolation | Operational cost | Migration difficulty later |
|---|---|---|---|
| Shared schema, tenant ID | Logical only | Lowest | High |
| Schema per tenant | Moderate | Medium | Medium |
| Database per tenant | Strong | High | Low - already separated |
| Cell-based (pools of tenants) | Strong at cell level | Medium-high | Low |
02Billing is where scope is most often underestimated
Billing looks like a payment integration and is actually a domain model. Proration on mid-cycle changes, usage metering that agrees with what customers can see, plan changes that apply at the right boundary, tax by jurisdiction, dunning when a card fails, and credits when something goes wrong - each one is a rule with edge cases, and together they are frequently the most defect-prone area of a SaaS platform.
The tell is a proposal with a single line item for billing. Ask specifically how usage is metered, where the source of truth for entitlement sits, and what happens when the metering data and the invoice disagree - because they will.
03Ask what enterprise readiness they have actually shipped
The features that gate enterprise deals are consistent and rarely in an MVP scope: single sign-on via SAML or OIDC, SCIM provisioning, role-based access that customers can configure themselves, audit logs the customer can export, and data residency options.
None are technically exotic. All take longer than expected, and retrofitting authorisation in particular is expensive because permission checks end up scattered through a codebase that assumed a simpler model. A vendor who raises these before you do is one who has hit them.
- SSO and SCIM: assume enterprise deals will require both
- Customer-configurable roles, not roles hardcoded per deployment
- Audit logs the customer can query and export themselves
- Data residency: at minimum, know what changing region would cost
04Establish who operates it before the build starts
A SaaS platform is not delivered, it is run. If the build partner hands over at launch, someone must be ready to take on-call, respond to incidents, apply security patches and manage capacity from day one. That team needs to exist and be involved during the build, not recruited after it.
The alternative is a managed arrangement where the partner continues to operate the platform under a defined service level. Both work. What does not work is leaving it undecided until launch, which is common and reliably produces a period where nobody is clearly accountable for the system being up.
Topics
Lena Voss
Lead Architect · SyncTrix
Writes about the engineering decisions behind production systems - architecture, delivery and the trade-offs that only show up at scale.
Building something like this?
SyncTrix engineers AI, SaaS, platform and cloud systems for enterprises and high-growth teams. Tell us what you're shipping and we'll scope it with you.