Multitenant Plugin Laravel Package

Product Decisions This Supports

Build vs. buy for the tenant admin surface. This package is best understood as a thin Filament admin layer over stancl/tenancy — not a tenancy engine. That reframes the decision: the expensive, risky part of multi-tenancy (data isolation, connection switching, tenant lifecycle) is delegated to a mature upstream library, while this package supplies the screens and wiring for creating, listing, and managing tenants inside a Filament panel. If we are already committed to Filament + stancl/tenancy, the buy case is "a few days of admin UI for free." If we are not, this package is not the reason to adopt either.

Accelerating a specific roadmap item, not a platform bet. The right framing is a scoped acceleration: it shortens the path to a demo-able tenant provisioning flow for an internal tool, an early-access SaaS pilot, or a back-office console. Treat it as a schedule lever on one deliverable, not as a foundational platform commitment.

Feature scoping questions it forces us to answer early. Adoption pressures us to decide, on the record: who creates tenants (self-serve vs. operator), what tenant lifecycle states exist (provision / suspend / delete), whether tenant data isolation is schema-per-tenant or database-per-tenant, and what "delete a tenant" means for data retention and compliance. These are product decisions, and getting them written down is worth more than the package itself.

Buy vs. build the admin UI. Building equivalent tenant CRUD in Filament is genuinely small — likely 3–10 engineering days including tests. That is the honest comparison price. The package wins only if (a) its opinions match ours, and (b) we accept taking a maintenance dependency whose upstream is a single maintainer with 1 GitHub star and a release tag shipping with empty release notes.

Roadmap signal — multi-tenancy readiness. If multi-tenancy is on the roadmap beyond one pilot, the decision that matters is the engine choice (stancl/tenancy vs. alternatives vs. in-house) and the tenancy model. This plugin should be scoped as a swappable UI convenience inside that decision, explicitly non-strategic, and documented as such so it never becomes load-bearing.

Discovery flag for the first spike. The package description claims request-level tenant resolution and middleware, while the repository tagline describes a Filament tenant-management plugin. Those imply very different blast radii — admin-only vs. in the request path of every tenant request. Resolving that ambiguity is the first deliverable, because it changes the risk profile from "cosmetic dependency" to "production path dependency."

When to Consider This Package

Consider it when all of the following hold:

• We have already chosen Filament for the admin panel and stancl/tenancy as the tenancy engine. In that specific stack it is additive and cheap.
• The need is an internal or operator-facing tenant console for a pilot, demo, or early-access programme — not a hardened, high-scale production control plane.
• We can adopt it behind a seam we own (our own service/interface for tenant provisioning), so package types do not leak into domain code and removal is a contained change.
• We can prove on one non-critical service that it does not force schema migrations or config we would then own, and that the uninstall test passes — no residue in schema, config, or container bindings.
• A named engineer owns the dependency, watches upstream releases, and maintains our own changelog and pinned-version policy in place of the missing upstream release notes.
• The licence (MIT) and the resulting obligation set are consistent with how we distribute.

Look elsewhere — or build the small admin CRUD ourselves — when:

• We are not on Filament, or not on stancl/tenancy. The package's value collapses to a handful of screens; building them is cheaper than adopting an unrelated stack.
• The requirement is production-grade tenancy with audit, compliance, per-tenant billing, or strict data-residency guarantees. Those are product and data-architecture decisions this package does not make for us.
• Supply-chain governance is strict. One star, a single maintainer, no release notes, no published supported-version matrix, and no documented deprecation or upgrade path is a governance gap, not a documentation nit. In a regulated or high-availability context this alone is disqualifying until the maintainer publishes release documentation.
• We need assurance on framework upgrade cadence. A tightly pinned package makes the maintainer's release timing our own; if we cannot tolerate waiting on a third party for a Laravel major, we should not inherit that dependency.
• The evaluation cannot be timeboxed or cannot secure a spike environment. Without a bounded spike and an exit test, the risk is unbounded.

How to Pitch It (Stakeholders)

For executives — one paragraph. We are evaluating a small, MIT-licensed add-on that gives our Laravel/Filament applications a ready-made screen for creating and managing customer tenants. It does not invent tenancy; it wraps an established open-source tenancy library. The upside is schedule: it could save a few engineering days on a pilot or internal admin console. The downside is supply-chain: it is maintained by one person, has negligible community traction, and shipped its 1.0 release without release notes or a supported-version matrix. Our recommendation is therefore conditional and deliberately narrow: timeboxed spike, one non-critical service, behind a seam we control, with a proven uninstall. We are not proposing it as a platform standard, and we will not expand it to a second service without measured benefit.

For engineering — the ask. Run a two-to-five day spike on one low-criticality service. Confirm the PHP/Laravel version matrix by actually installing it, not by inference. Determine whether it stays in the admin panel or enters the request path via middleware — that distinction drives the entire risk assessment. Wrap all usage behind an interface we own. Then execute the uninstall test and record the result. Write a short internal note so the learning outlives the spike branch, and file a decision record covering the seam, the version-pin policy, the owner, and the rollback procedure. If the package lags a Laravel major, or if removal leaves residue, we stop and build the equivalent Filament screens in-house — the estimated cost of doing so is small enough that we should never feel trapped.

The one-line framing to keep everyone aligned. This is a convenience layer, not a commitment: buy it to save days, scope it so we can drop it in a week, and never let it own our tenancy model.