001 · Technical case study
B2B platform with strict per-organisation isolation, dual-layer payments (platform subscription + connected accounts with split payouts) and an OAuth integration layer extensible to any provider.
Plain English
Picture an office building. Every company that signs up rents its own office inside the same building: their desk, their cabinets, their keys. They share the building, the lift and the wifi — but no company ever sees another's paperwork.
In code that translates to: one app, one server, but each customer gets their own isolated database. When a user signs in, the system reads the URL, works out which company they belong to, and only gives them access to THEIR database. Company A literally cannot reach Company B's data.
The trick: one architecture, infinite customers. Without spinning up 50 separate installs, 50 servers, or 50 deploys.
1 app
One codebase,
one deploy
N customers
Each one,
their own world
0 leaks
Full
isolation
The building, drawn
/tenant-001/dashboard and /tenant-002/dashboard run the exact same code — but read and write to different databases. The first URL segment is the key that only opens THEIR office.
By the numbers
Snapshot of the production repo — counted directly from source.
Migrations
35 central · 67 tenant
Eloquent models
Domain entities
Controllers
Inertia + REST
Services
Business logic
Background jobs
Horizon queues
Vue files
82 pages · 179 components
LOC routes
6 route files
OAuth providers
Pluggable layer
Schema map
Central DB owns identity, billing and tenancy metadata. Each tenant DB owns its full domain.
Central DB
Identity · Billing · OAuth
Tenant DB
Per organisation · Isolated
Module map
How the 32 models cluster into bounded contexts. Each module owns its own services, jobs, and routes.
Path-based isolation, central users, cross-DB permissions.
Dual-layer subscriptions: platform Cashier + per-account billing.
Per-tenant + central OAuth configs + state manager.
Posts, stories, scripts, accounts — the content domain.
Time-series snapshots of accounts and posts for trend analysis.
Per-tenant settings, send log, queued delivery via Brevo.
Spatie MediaLibrary on S3 + comment threads on scripts.
Self-rescheduling fan-out — see the deep-dive →
01
Architecture · Isolation · Routing
Built on stancl/tenancy 3.9 with path-based identification: every request resolves tenant context before the controller, switching DB, cache, filesystem and queue connections.
InitializeTenancyByPath middleware resolves the tenant from the first URL segment and switches the active DB, cache and filesystem connections before the controller runs. The whole functional domain lives under /{tenant_id}/… without colliding with central routes.
Each organisation gets its own database (tenant{id}) with 27 tables migrated via artisan tenants:migrate. The central DB only holds 16 globally-scoped tables: tenants, domains, users, billing, OAuth configs.
Users live in the central DB but are referenced from tenant DBs via central_user_id as a string — no physical FKs. CentralUser::can() overrides Spatie Permission to always resolve against the central connection, regardless of the active context.
A ClearPermissionCacheForTenancy middleware purges the permission cache when entering tenant context, killing the classic cross-authorisation bug that appears when workers are reused across tenants.
02
Dual-layer · Connected accounts
Two money flows living on the same infrastructure — uncoupled, non-overlapping, with deterministic access rules.
The platform charges each tenant via laravel/cashier 15. CheckTenantSubscription middleware intercepts every request to the tenant namespace and blocks access unless three invariants hold: a valid subscription ID, status active or trialing, and a future current_period_end.
Per-tenant onboarding of connected accounts so they can charge their own end customers. StripeConnectService orchestrates destination charges to the merchant account with automatic split payouts and an application fee retained on every transaction. Webhooks reconcile each connected account's state.
// access invariants — checked on every tenant request
public function isPaid(): bool
{
return $this->stripe_subscription_id
&& in_array($this->status, ['active', 'trialing'])
&& (!$this->current_period_end || $this->current_period_end->isFuture());
}03
6+ providers · pluggable
Un único OAuthService abstrae la lógica común; cada provider añade un controller especializado.
04
Tenant onboarding flow
Manager registers ┌──────────────────────┐
on /register ───▶ │ CentralUser created │
└──────────┬───────────┘
│
▼
┌──────────────────────┐
│ Tenant + Domain │ ◀─── tenants:create
│ central_subscription│
└──────────┬───────────┘
│ tenants:migrate
▼
┌──────────────────────┐
│ Tenant DB seeded │ 27 tables
│ permissions cleared │ ClearPermissionCache
└──────────┬───────────┘
│ first request
▼
┌──────────────────────┐
CheckTenantSubscr. │ isPaid()? ───── no │ ───▶ /billing
────────────────────▶│ │ │
│ yes │
│ ▼ │
│ Dashboard │
└──────────┬───────────┘
│
┌──────────────────┼──────────────────┐
▼ ▼ ▼
┌──────────┐ ┌────────────┐ ┌─────────────┐
│ Connect │ │ Connect │ │ Create │
│ social │ │ Stripe │ │ publication │
│ accounts │ │ account │ │ draft │
└──────────┘ └────────────┘ └─────────────┘05
External services orchestrated
06
Async · Deploy · Quality
07
Production dependencies — curated
Core
Tenancy
Payments
Async · Realtime
Integrations
Quality
End of case study