The architectural decisions that are cheap on day one and brutally expensive on day three hundred.
Adding a tenant_id column to every table costs almost nothing when you do it from the first migration. Retrofitting it after a hundred tables and a year of customer data is a multi-week project with real risk of leaking one customer's data into another's view.
The same goes for auth: building it around an organization concept from the start, even with a single user per org at launch, avoids a painful rewrite the day the first customer asks to invite teammates.
Shared schema with a tenant_id, schema-per-tenant, or database-per-tenant — each has a different cost curve for isolation, operational complexity, and per-tenant customization. The wrong choice isn't fatal, but switching later means a migration with the business running on top of it.
For most B2B SaaS products, shared schema with strict row-level isolation is the pragmatic default — it scales operationally further than people expect, and you can carve out dedicated infrastructure for the handful of customers who actually need it.
Synchronous background jobs that worked fine for one customer's data volume can silently degrade once ten large customers share the same queue. Multi-tenancy turns "it's a bit slow" into "customer A's report job is starving customer B's."
Per-tenant rate limiting and queue isolation are easy to bolt on early and genuinely hard to retrofit once a few large accounts depend on the system behaving predictably under load.
You don't need to build the full multi-tenant version before the first customer. You need to avoid the handful of decisions — identity model, data isolation boundary, and background job ownership — that are cheap now and expensive later, and defer everything else.