SaaS Development: The Parts Nobody Warns You About

Founders usually arrive with a clear picture of what their SaaS product does, and almost no picture of the machinery underneath it. That machinery is most of the work. A product that does one useful thing for one customer is a weekend prototype; making it safe for a thousand customers who must never see each other is the actual engineering.

Multi-tenancy: decide this first, change it never

How you separate one customer from another is the single decision that is most expensive to reverse. There are three common approaches. A shared database with a tenant column on every table is cheapest to run and easiest to query across customers, but one missing filter in one query leaks data between them. A database per tenant is far safer and simpler to reason about, but migrations and backups multiply. A hybrid keeps shared reference data central and tenant data separate.

For most B2B products we start with a shared database and enforce the tenant filter globally rather than query by query, so it is impossible to forget.

// A global scope means no query can accidentally omit the tenant filter.
// Enforcing it per query is where cross-tenant data leaks come from.
class TenantScope implements Scope
{
    public function apply(Builder $builder, Model $model)
    {
        if ($tenantId = auth()->user()?->tenant_id) {
            $builder->where($model->getTable() . ".tenant_id", $tenantId);
        }
    }
}

Billing is a product, not a feature

Subscriptions sound simple until you list the states: trials that end, plans that change mid-cycle, cards that fail, refunds, proration, annual versus monthly, tax by jurisdiction, and the grace period before you suspend an account. Each of those is a decision with support consequences. Use an established payment provider and model your own subscription state alongside theirs, so a webhook that arrives late does not lock out a paying customer.

"A SaaS product is judged on the day something goes wrong with a payment, not on the day the feature ships."

Onboarding decides whether trials convert

Most trial users who churn never reached the point where the product became useful. Work out what that point is for your product, whether it is importing data, inviting a colleague or completing one real task, and design the first session to reach it. Empty dashboards convert nobody, so seed a new account with sample data they can delete.

Plan for the operational load

A SaaS product is a service you run, not software you deliver. That means monitoring, on-call, a backup restore you have actually rehearsed, and a way to deploy without disconnecting users mid-task. Budget for it from the start: teams that skip it spend their second year firefighting instead of building.