SaaS Development with Laravel
Make the few SaaS decisions that are costly to reverse, such as tenancy, billing unit and permissions, before the first customer signs up.
1 Overview
A SaaS product is one application that many customers use at once, each seeing only their own data and each paying on a recurring basis. Laravel covers most of the groundwork: login, background jobs, scheduled tasks, mail, and official packages for subscription billing. Building features is therefore rarely the hard part. The hard part is a handful of structural decisions that are cheap on day one and expensive once real customer data exists.
Multi-tenancy: how customers are separated
A tenant is one customer account, usually a company with several users. There are three common models.
- Shared database: all tenants are in the same tables, and every record carries a tenant ID. Cheapest to run and simplest to update. The risk is a query that forgets the tenant filter, so the filter must be applied automatically and verified by tests.
- One database per tenant: stronger separation, simple export, backup and deletion per customer, and possible storage in a specific region. In exchange, every database change has to be rolled out to all tenants, and reports across customers become harder.
- One installation per tenant: full isolation for customers with strict requirements, at the highest operating cost.
Most products start well with a shared database. Choose separate databases if customers will contractually demand separation or individual restore. Switching later means migrating live data. Decide at the same time how a tenant is recognised: by subdomain, by the customer's own domain, or by selection after login.
Users and accounts
Can one person belong to several tenants with the same login, for instance a consultant working for three clients? If so, roles belong to the membership and not to the user. Adding this afterwards touches nearly every screen, so settle it early.
Roles and permissions
Start with a small number of fixed roles, such as owner, administrator and member, and check permissions in one central place rather than scattered across pages. Ask whether customers will later want to define their own roles; if that is likely, design permissions as individual abilities from the start. Plan a way for your support staff to view an account as the customer sees it, with a log of every such access.
Subscription billing
Payment handling is delegated to a billing provider, which Laravel connects to through its billing packages. The decisions that remain are yours:
- What is the billing unit: a flat price per account, per user, or by usage? Changing it later means changing contracts, not only code.
- Is there a trial, and what happens when it ends without a payment method?
- What happens on a failed payment: how many reminders, how long a grace period, then read-only or locked?
- How are upgrades and downgrades in mid-period settled?
- Where are plan limits enforced? Define what each plan allows in one central place.
The subscription status in your application has to follow the provider's notifications, not the result of the checkout page. Invoicing and tax rules for customers in different countries should be clarified with a tax adviser before the first sale.
Queues and background work
Everything that takes time or depends on another system runs in the background: emails, imports, exports, report generation, incoming billing notifications. Two points are specific to SaaS. Each job must know which tenant it belongs to, and one customer starting a huge import must not hold up everyone else, which calls for separate queues or limits per tenant.
Onboarding
The path from registration to the first useful result decides whether a trial turns into a subscription. Plan it as a feature: registration with as few fields as possible, example data or a guided first step, inviting colleagues, and importing existing data.
Decide before launch
- tenancy model and how tenants are identified
- whether a user can belong to several accounts
- billing unit and plan structure
- export and complete deletion of a customer's data on contract end
- an audit log of who changed what
Contract terms, data processing agreements and privacy obligations need a lawyer, not a developer.
2 Who this is for
Founder
You see which decisions to settle before development starts, because changing them later means migrating customer data or rewriting contracts: tenancy model, billing unit, and whether one user can belong to several accounts.
CTO or tech lead
You get the trade-offs between shared database, database per tenant and separate installations, plus the SaaS-specific points for queues, permission checks and keeping subscription status in step with the billing provider.
Product manager
You get the product questions that development cannot answer for you: trial and failed-payment rules, plan limits, fixed or customer-defined roles, and the onboarding path from registration to the first useful result.
3 Questions and answers
Should every customer of a SaaS product get a separate database?
Not by default. A shared database with a tenant ID on every record is cheaper to operate and easier to update, and it is sufficient for most products if the tenant filter is applied automatically and tested. Separate databases are worth their extra operating effort when customers demand contractual separation, individual restore or storage in a particular region.
Why is Laravel a reasonable choice for building a SaaS product?
It ships with the parts every SaaS needs: authentication, queues, scheduled tasks, mail and notifications, plus official packages for subscription billing. That leaves the budget for the product itself. Its limits are the same as for any single application: very high load or unusual real-time requirements need additional architecture, which should be judged on your concrete case.
Can the pricing model of a SaaS be changed after launch?
Prices and plan contents are easy to change if plan limits are defined in one central place. Changing the billing unit, for example from a flat fee to a price per user or by usage, is harder: the application must start counting something it did not count before, and existing customers need a transition rule. Decide the unit early and keep the plans themselves flexible.
5 From the blog
Planning a project like this?
Tell us what you are building. You get a straight answer on scope, approach and effort.