What this prompt does
This prompt makes the AI act as a senior Laravel engineer and hand back a complete, drop-in multi-tenancy layer rather than a high-level explanation. You tell it your [laravel_version], your [tenancy_model], and your [auth_stack], and it produces the migrations, the global scope or trait, a TeamPolicy, middleware, an invitation flow, and a switch-team endpoint. The output is structured as six deliverables so nothing critical gets skipped.
The structure works because tenancy bugs are not random — they cluster in predictable places. By forcing the AI to name where tenancy leaks (queue jobs, un-scoped global queries, admin panels), the prompt converts a vague "make it multi-tenant" request into a concrete checklist. The [tenancy_model] variable is the most consequential: a single-database team_id approach produces very different code from a database-per-tenant model, so setting it precisely steers the entire answer. [auth_stack] tells the AI how to read the current team per request (Jetstream, Filament, plain Sanctum all differ).
When to use it
- You're starting a new team-based SaaS and want the isolation layer correct from commit one.
- You're retrofitting tenancy onto a single-tenant app and need a migration plan.
- You keep worrying that a missing scope will let one team read another's rows.
- You need an invitation + role flow and a switch-team endpoint scaffolded together.
- You're using Filament or Nova and want the admin panel covered, not just the web app.
- You want a written list of the exact spots where forgetting the scope leaks data.
Example output
You get a set of fenced code blocks: a migration set defining teams, memberships, and team_id foreign keys; a global scope or BelongsToTeam trait that auto-filters tenant-owned queries; a TeamPolicy plus middleware that blocks cross-team access even with a guessed ID; an invitation/accept/roles flow; and a switch-team endpoint. It closes with a usage example and an explicit callout of the three leak-prone areas and how to plug each.
Pro tips
- Set
[tenancy_model]exactly — "single database with ateam_idcolumn" yields very different code than database-per-tenant, and a vague value gives a vague answer. - Match
[auth_stack]to your real stack so the "set current team per request" code fits; Jetstream, Filament, and bare Sanctum resolve the team differently. - Pin
[laravel_version]to your actual version so the migration and scope syntax matches; mixing Laravel 10 and 12 idioms causes subtle breakage. - Lean hardest on deliverable 5 (the leak spots) before you ship — queue jobs that lose the current-team context are a classic source of cross-tenant bleaks.
- Ask a follow-up to add tenant-aware tests; verifying that Team A genuinely cannot fetch Team B's rows is worth writing down.
- If you use Filament, explicitly confirm the admin panel respects the scope, since admin queries often bypass it.
