SaaS Product Development

A handful of decisions made in the first few weeks of a SaaS build determine how painful the next three years are. Most of them are cheap to get right at the start and become migrations — sometimes migrations requiring downtime — once you have customers.

Multi-tenancy, decided deliberately

Three broad models, and the right one depends on your customers rather than on preference. A shared schema with a tenant identifier on every row is simplest to operate and cheapest to scale, but every query must be scoped correctly and one missed filter is a data leak between customers. A schema per tenant gives stronger isolation at the cost of migrations that must run across every schema. A database per tenant offers the strongest isolation and the highest operational overhead, and is usually driven by enterprise or regulatory requirements.

Most products should start with a shared schema and enforce scoping at the framework level rather than by remembering to add a where clause — a global scope or repository layer that makes an unscoped query difficult to write by accident.

Billing, which is harder than it looks

Subscriptions appear simple and then you meet mid-cycle upgrades and downgrades, proration, annual plans with monthly add-ons, usage-based components, trials converting or lapsing, failed payments and dunning, refunds, credits, tax by jurisdiction, and an invoice a customer disputes eight months later.

Use a billing provider — Stripe or similar — rather than building it. But do not let the provider be your only record: keep your own subscription state and invoice history, treat webhooks as the sync mechanism, and reconcile periodically. Providers get replaced; your billing history has to survive that.

The decisions that are painful to reverse

• Identifiers. Sequential integers in URLs leak your customer count and invite enumeration. Opaque identifiers cost nothing at the start.
• Money. Minor units as integers, never floats, with the currency stored alongside. Retrofitting multi-currency onto a single-currency schema is genuinely unpleasant.
• Time. UTC everywhere, converting at the edges, with the user's timezone stored explicitly. Reporting that spans regions exposes shortcuts here immediately.
• Soft deletes and audit. Customers will ask what changed and who changed it. Adding an audit trail retroactively gives you history starting from the day you added it.
• Permissions. Role-based access designed early, because bolting granular permissions onto a system with two hardcoded roles touches every endpoint.

Onboarding and the first session

Where most SaaS products lose users. An empty account with no obvious next step converts poorly regardless of how good the product becomes later. Sensible defaults, sample or seeded data, and a first-run path to something that demonstrates value beat a feature tour.

Technically this means the invite and team setup flow, email verification that does not block exploration, and — for anything with a real setup cost — the ability to import existing data rather than start from nothing.

Building less, deliberately

For an early-stage product, my most useful contribution is often arguing for a narrower first release. Fewer configurable options, decisions deferred until there is evidence, and features left out until someone asks twice.

Configurability in particular is a trap: every setting is a permutation to support, test and document forever. A product with opinions is easier to build, easier to explain and easier to change than one that tries to accommodate every workflow before knowing which ones matter.

Getting a prototype to production

A common engagement: something works, has users, and was built quickly. The gap to production is usually not features — it is tests on the paths where failure is expensive, a deployment pipeline, environment parity, monitoring, backups that have been restored from, and the multi-tenancy scoping that was assumed rather than enforced. See DevOps & CI/CD for the delivery side of that.

Common questions