Building a Multi-Tenant SaaS in Laravel: The Series I Wish I Had Read First: 01 of 08

This is the article I would have wanted to read before I started building a multi-tenant system. It would have saved me time, a lot of rewritten code, and many hours migrating systems that were already running. Most of the expensive decisions in a multi-tenant SaaS are cheap on day one and costly on day four hundred. Where the tenant lives in the schema, how a request finds its company, what a background job knows about who it works for: you can get each of them right in an afternoon at the start, or fix them later with a migration, a rewrite and a nervous deploy. I know the second path because I have walked it. This series is what I would do on the first day if I started again, knowing what I know now. Here is one of those paths. I started multi-tenant, but not multi-user. Adding multi-user later wasn't a feature. It was a rewrite that touched the whole system. And the guards that kept one tenant's data away from another weren't built as well as they should have been. Both problems sit at the foundation, which is why the first article of the series deals with who belongs to which company and how a request finds out. What This Series Is It is a set of decisions with reasons attached, written for developers who already build with Laravel and want to design and deliver a multi-tenant SaaS without learning the hard parts the slow way. Every article follows the same fictional product, an invoicing app where the tenant is a Company, so the examples connect from one article to the next. It is not a package guide, and it is not a framework. You won't find a library to install that solves tenancy for you. You will find the pieces I think are worth building yourself, why, and what each one costs. Where a decision is a judgment call, I say so. What It Assumes A few choices are fixed so the series can go deep instead of wide: One Laravel application and one database, with a company_id column on tenant-owned tables. If you are still deciding between a modular monolith and microservices, that is a different question, and I wrote about how to approach it in Modular Monolith or Microservices: A Framework for Deciding Without Dogma. Laravel 13 and PostgreSQL in the examples, although most of it applies to other versions and to MySQL. The one article that depends on PostgreSQL says so up front. A reader with some experience. I don't explain what a middleware or a queue is. What it leaves out on purpose: a separate database per tenant, single sign-on, and the details of any specific payment provider. Each is worth its own series, and none of them is where a first version usually hurts. What You'll Find These are the articles in the order I would read them. Each one stands on its own once you know the tenant context from the first. I update this list as the series is published: a title with a link is already out, and a title without one is still to come. Multi-Tenant SaaS in Laravel: One Database, a Global Scope, and the Leaks It Doesn't Catch. The foundation: how a request finds its company, a scope that fails closed, and what the scope still misses. Killing Fat Controllers in Laravel: Actions as the Home for Business Logic. Where the rules live, so a controller, a command and an API share one implementation. Data Objects, Concerns and Events: The Supporting Cast of a Laravel Action. What feeds an Action, what it shares and what it announces, with the tenant context carried into queued listeners. From Idea to First Paying Customer: A Delivery Roadmap for a Multi-Tenant Laravel SaaS. The order of work: walls before rooms, one slice early, plan limits, billing webhooks and safe deploys. Testing Tenant Isolation in Laravel: Leak Tests, Guard Tests and What They Still Miss. How to prove, on every commit, that one company can't see another. Observability Per Tenant in Laravel: Logs, Metrics and Errors by Company. How to answer "what happened to this company?" without drowning in data. Row-Level Security in PostgreSQL: A Second Wall for a Multi-Tenant Laravel App. An optional database-level layer behind the application scope, and the cases where it is worth its cost. How to Read It Two habits will help. First, treat the code as a starting point. The snippets are small on purpose, and I haven't run them against your schema, your policies or your deploy setup. Second, pay attention to the cost sections. Every pattern here has a price, and the honest question is not "is this good practice?" but "is it worth it for my team, at my size, this year?" Sometimes the answer is no. A pass-through Action, a Data object for two arguments or a database policy for a prototype are all ways to spend effort you needed elsewhere. Conclusion I'm writing this series because the most useful advice I can give my past self is also the advice most teams hear too late: decide the foundations early, make them testable, and keep the rest boring. If you are about to start a multi-tenant product, or you are early enough that the foundations can still change, begin with the tenant context. Everything else in the series is built on it.