Most SaaS rewrites aren't caused by bad code — they're caused by architectural decisions that made sense at 10 users and stopped making sense at 10,000. In this piece, we walk through the handful of decisions worth getting right from day one: multi-tenancy strategy, background job design, and how to keep your data model flexible without over-engineering it.
We'll cover row-level tenancy vs. schema-per-tenant, why queues beat cron jobs for anything user-facing, and how to instrument your app so you find bottlenecks before your customers do.
Pick your tenancy model early
Row-level tenancy (a single shared schema with a tenantId column) is the right default for most SaaS products — it's simpler to operate and query across tenants for internal reporting. Schema-per-tenant only earns its complexity when you have strict compliance requirements around data isolation.
Queues, not cron
Anything triggered by a user action — sending an email, generating a report, syncing to a third-party API — belongs in a queue with retries, not a cron job that runs every five minutes and hopes for the best.