How to Build a Multi-Tenant SaaS with Laravel 13 — From Architecture to Deployment

Last updated: August 2026 · ~12 min read

Want to build SaaS with Laravel? This architecture guide walks through how I design multi-tenant SaaS with Laravel 13-era patterns — from tenancy model to deployment — using the same decisions I make on paid client builds.

I'm Arun Tyagi, a freelance Laravel SaaS developer in Noida. If you need the commercial page: Laravel SaaS Development Services India.

Build SaaS with Laravel 13 — the decisions that matter first

Framework version hype is a distraction. Whether you are on the latest Laravel release train or one minor behind, SaaS success depends on five decisions:

1. Tenancy model — shared database vs database-per-tenant
2. Identity model — users belong to organisations; roles are organisation-scoped
3. Billing — Stripe Cashier or Razorpay with idempotent webhooks
4. Feature flags — Laravel Pennant (or equivalent) so you can ship dark
5. API boundary — Sanctum for SPA/mobile; never trust the client for tenancy

Get these wrong and you rewrite at customer 50. Get them right and Laravel will carry you further than most founders expect.

Tenancy: shared database + global scopes (default for most startups)

For early B2B SaaS I usually recommend shared database multi-tenancy with a workspace/organisation id on every tenant-owned row. Isolation is enforced with Laravel global scopes — not “remember to add where() in every query.”

// app/Models/Concerns/BelongsToOrganisation.php
public static function bootBelongsToOrganisation(): void
{
    static::addGlobalScope('organisation', function (Builder $builder) {
        if ($orgId = app('currentOrganisationId')) {
            $builder->where($builder->getModel()->getTable().'.organisation_id', $orgId);
        }
    });

    static::creating(function ($model) {
        if (! $model->organisation_id && $orgId = app('currentOrganisationId')) {
            $model->organisation_id = $orgId;
        }
    });
}

Then every tenant model uses the trait. Feature tests assert Tenant A never reads Tenant B rows — including nested resources and API endpoints.

When I use stancl/tenancy: when the product truly needs database-per-tenant (enterprise isolation, per-tenant migrations, or regulated data). The package is excellent, but ops cost is real: more databases, more migration surface, more backup complexity. Most seed-stage SaaS products do not need it on day one.

// Conceptual stancl-style identification (package docs evolve — pin a version)
// Central domain identifies tenant; tenant connection swaps for the request.
Tenancy::initialize($tenant);

Decision rule I use with founders: start shared DB + scopes unless a paying enterprise contract requires hard isolation. Re-evaluate at Series A, not at the landing-page stage.

Billing: Cashier webhooks before polish

Laravel Cashier (Stripe) is my default for international SaaS. For India-first products I often use Razorpay with a similar webhook-first design. The mistake is building beautiful pricing UI before failed payments, proration, and trial endings are modelled.

// routes/web.php (Cashier-style webhook)
Route::post(
    '/stripe/webhook',
    '\Laravel\Cashier\Http\Controllers\WebhookController@handleWebhook'
)->name('cashier.webhook');

Handlers must be idempotent. Log every event id. Surface failed invoices in admin. Queue receipt emails. I have rescued SaaS products where billing “mostly worked” until the first bank decline — then support exploded.

Feature flags with Laravel Pennant

Pennant (or a thin custom flag table) lets you ship incomplete modules to staging users without exposing them to every tenant.

use Laravel\Pennant\Feature;

Feature::define('new-billing-portal', fn (User $user) => $user->isInternal());

if (Feature::active('new-billing-portal')) {
    // new UI
}

On past SaaS projects this prevented “big bang” launches. We turned modules on per organisation after a successful pilot.

API + SPA/mobile pattern

Many Laravel SaaS apps pair a Laravel API with React or Next.js. Keep authorization and tenancy on the server. Sanctum tokens for SPA/mobile:

// routes/api.php
Route::middleware('auth:sanctum')->group(function () {
    Route::get('/projects', [ProjectController::class, 'index']);
});

In the controller, rely on the global scope — do not accept organisation_id from the client as a trust boundary. Paginate consistently. Version endpoints when mobile clients cannot force-upgrade overnight.

Admin, queues, and observability

Filament (or a custom admin) is mandatory for support. Without it, you SSH into production to reset a password — that does not scale. Queues handle mail, invoices, exports, and webhook fan-out. Horizon (Redis) makes failed jobs visible.

Minimum launch observability:

• Error tracking (e.g. Flare/Sentry)
• Failed job dashboard
• Billing webhook log
• Uptime check on /up

Deployment checklist I actually use

1. Staging environment with anonymised data
2. Automated tenant isolation tests in CI
3. Zero-downtime deploy strategy (or maintenance window documented)
4. Database backups tested with a restore drill
5. ENV secrets not in git; APP_KEY rotated only with a plan
6. Runbook: rollback, pause webhooks, pause queues

Real decisions from past SaaS work

On a payments-style platform (see PayBev), we prioritised transaction integrity and admin visibility over fancy dashboards. On marketing-ops platforms, staging verification before every production release mattered more than microservices. On charity/donation products for UAE-facing clients, recurring billing edge cases and multi-language content were first-class — not afterthoughts.

Pattern: boring architecture that survives week 12 beats clever architecture that impresses week 1.

When to hire vs DIY

If you are still choosing between Node and Laravel, read this guide and decide. If you already know you need production tenancy and billing in 8–14 weeks, hire help: Laravel SaaS Development.

Related: Multi-tenant SaaS on Laravel (deep dive) · Build SaaS with Laravel overview · Book a call.

Package shortlist I actually recommend

• Laravel Cashier — Stripe subscriptions and customer portal hooks
• Laravel Sanctum — SPA/mobile API tokens
• Laravel Pennant — feature flags per user/organisation
• stancl/tenancy — only when database-per-tenant is a hard requirement
• Filament — admin/ops panels without reinventing CRUD
• Horizon — queue visibility on Redis

Resist installing tenancy packages “just in case.” Every package is a permanent dependency. Prefer Laravel primitives until a requirement forces the upgrade.

Domain events and async work

SaaS products accumulate side effects: welcome emails, usage metering, invoice PDFs, Slack alerts, CRM sync. Put them on queues. Name jobs clearly. Make them retry-safe. When a webhook handler does five synchronous HTTP calls, one slow partner takes your billing endpoint down.

InvoicePaid::dispatch($invoice);
// listener: SendReceipt, UpdateUsage, NotifySlack — each queued

Security basics that founders skip

• Policies/gates for every organisation-scoped action
• Rate limits on login and password reset
• No secrets in front-end bundles
• Signed temporary URLs for exports
• Regular dependency updates (Composer + npm)

I have audited Laravel SaaS apps where tenancy was correct but a single export endpoint leaked CSV files across organisations. Architecture diagrams do not catch that — tests and code review do.

A sample Phase-1 scope that ships

When founders ask me to build SaaS with Laravel, Phase 1 usually includes: organisation accounts, invite/join flow, roles (owner/admin/member), one core workflow (5–8 screens), subscription checkout, basic admin, and staging. Everything else — analytics dashboards, marketplace messaging, AI features — waits for Phase 2 after real usage. That discipline is how 8–14 week MVPs actually launch without rewriting the tenancy model mid-sprint. If your pitch deck has twenty epics, we will still ship five that prove the core loop.

FAQ — build SaaS with Laravel

Is Laravel good for SaaS in 2026?

Yes — for most B2B SaaS, marketplaces, and internal platforms. Queues, auth, billing ecosystems, and PHP hiring depth in India make it a pragmatic default.

Do I need stancl/tenancy on day one?

Usually no. Shared database + global scopes is enough for most early products. Adopt database-per-tenant when contracts require hard isolation.

What does a Laravel SaaS MVP cost in India?

Typically ₹1.2L–₹4.5L for a lean multi-tenant MVP with billing and admin. Full breakdown: Laravel SaaS MVP cost India 2026. Billing launch checklist: Stripe & Razorpay webhooks. Service page with pricing table: Laravel SaaS development. Ready to scope a build? Book a free discovery call.