Building a SaaS product is a different discipline from building software, and the difference is concentrated in a handful of early decisions. They are easy to make casually because at one tenant they appear not to matter. By the fiftieth tenant, and particularly by the first enterprise buyer, they determine whether the platform grows or gets rebuilt.
The first is tenant isolation. There are three broad options: pooled, where all tenants share tables and are separated by a tenant identifier; siloed, where each tenant gets their own database; and bridged, somewhere between. Pooled is cheapest to run and hardest to get wrong safely - one missing filter in one query and a customer sees another customer's data, which is the kind of incident a young company does not recover from. Whichever you pick, the isolation must be enforced somewhere structural, such as row-level security in the database, rather than depending on every developer remembering. And you need a documented path to move a large customer to their own database later, because eventually one will demand it in a contract.
The second is identity, and specifically whether a user belongs to a tenant or exists independently and has access to tenants. Modelling users as belonging to exactly one tenant is simpler and is what most products do first. It breaks the day a consultant needs access to three of your customers, or two of your customers merge, or a single person legitimately works for two of them. Retrofitting the many-to-many model touches every permission check in the product.
The third is metering. If you might ever price on usage - seats, transactions, storage, API calls - the events that drive that price must be recorded from day one, immutably, at a granularity you can aggregate later. You cannot reconstruct last quarter's usage from a database that only stores current state, which means pricing experiments become impossible precisely when you most want to run them. Recording usage events you do not yet bill for is cheap; recreating history you never captured is not.
The fourth is configuration versus customisation. Every enterprise buyer will ask for something specific. Answering with code branches for individual customers is how a SaaS product quietly becomes a consultancy with a hosting bill - every subsequent release must be tested against every variant. The alternative is deciding early which dimensions are configurable, exposing those properly, and holding the line elsewhere. That line will be tested by your largest prospect, which is exactly why it needs to exist before they ask.
None of these is expensive to get right at the start. Row-level isolation, a flexible identity model, an append-only usage log and a configuration schema are perhaps a few weeks of thought and work in the first month. All four are expensive to change once real tenants depend on the current behaviour - not because the code is hard, but because migrating live customer data while the product keeps running is hard.
The pattern worth internalising: in SaaS, the things that are hard to change are almost never the features. They are the shape of the data and the boundaries between customers. Spend the early architectural attention there, and be comfortable being unsophisticated everywhere else.
