Filament Tenancy Laravel Package

Product Decisions This Supports

• Build vs. buy for multi-tenancy. This is a tenancy scaffolding package for Laravel + FilamentPHP (the Spanish/English notes describe it as the "multi-tenant SaaS plugin"), covering the boot process, tenant-aware user resolution, middleware, and admin-panel resources. The decision it informs is whether we spend engineering weeks re-implementing tenant resolution, middleware, onboarding, and admin navigation, or adopt a third-party 1.0.
• Roadmap sequencing for a SaaS/admin initiative. If tenant-scoped admin panels are on the near-term roadmap, this release moves the "tenancy plumbing" workstream from build to evaluate, letting the team spend its roadmap budget on product-differentiating features instead of infrastructure.
• Scope of billing in v1. The release "finalizes PayPalSettingsResource integration" inside the tenancy package — a concrete signal that the package takes an opinionated stance on payments. That forces an explicit product decision: adopt PayPal as the tenant-billing path, or budget to replace/extend that resource (e.g., Stripe) before first paying tenant.
• Time-to-market for a first tenant. Documentation now claims step-by-step "SaaS deployment and configuration" plus central-vs-tenant database setup guides, meaning a first multi-tenant environment can plausibly be stood up in days rather than sprints — relevant to launch-date commitments.
• Vendor/dependency risk posture. Single-vendor package (Angelito Systems S.A.C.), support routed to a personal email and WhatsApp, docs hosted on the vendor's own domain. This is a decision about acceptable supply-chain risk and whether we vendor/fork.
• Upgrade and maintenance budgeting. The release is the first stable cut after several betas; the notes list stabilizations rather than new capability. That informs whether we pin a version and freeze, or track releases.

When to Consider This Package

Consider it when:

• The stack is Laravel + FilamentPHP and the admin UI is Filament-based — the value is concentrated in Filament resources and navigation, not in generic tenancy.
• We need tenant provisioning, tenant-aware auth/middleware, and central-vs-tenant database setup for a SaaS admin, and we want that shipped rather than designed.
• Team size is small and tenancy is infrastructure, not differentiation; buying weeks of engineering is worth more than owning the code.
• PayPal is an acceptable (or replaceable) billing path for the initial tenant segment.
• We can accept a young 1.0 with a single maintainer, provided we pin versions, keep a fork-ready posture, and verify the license terms and Filament/Laravel version constraints before committing.

Look elsewhere when:

• The admin layer is not Filament — most of the package's value evaporates.
• Requirements include hard isolation, compliance, per-tenant migrations at scale, custom-domain routing at volume, or sharding — mature, widely adopted tenancy libraries plus Filament's own native panel tenancy are the safer foundation.
• Billing must be Stripe-first or multi-processor — the bundled PayPal resource becomes a removal task, not a feature.
• Procurement requires an SLA, security review, license clarity, or a supported vendor with a track record; the current support channel (personal WhatsApp) does not satisfy that bar.
• Engineering capacity exists to compose established tenancy libraries + Filament's built-in tenancy in-house, which is often lower total risk than an early-stage all-in-one plugin.

Open questions to close before adoption: license and commercial terms, supported Laravel/Filament versions, test coverage, backward-compatibility policy for 1.x, and a security review of the tenant-boundary middleware. Note also that the release notes link a changelog comparing v1.0.4...v1.0.4 and describe changes in general terms only — evidence of immature release hygiene. Mitigate by pinning the exact version, reading the diff ourselves, and vendoring the package.

How to Pitch It (Stakeholders)

For executives: A vendor has shipped the first stable (1.0) release of a multi-tenant add-on for our Laravel/Filament stack. It packages the unglamorous plumbing behind a SaaS admin — tenant setup, user resolution, middleware, tenant-aware navigation, plus a PayPal settings screen — and now ships with real setup and deployment docs, which is the difference between a demo and something we can run in production. The upside is schedule: weeks of infrastructure work we don't have to staff. The caveats are maturity and concentration risk — it is a small vendor with a single maintainer, support runs through a personal email and WhatsApp, and the release notes are thin. Recommendation: run a time-boxed pilot in a non-critical environment, verify license, supported versions, and test coverage, and treat it as a pinned dependency we are prepared to fork — not as a foundational platform commitment.

For engineering: Treat v1.0.4 as the first credible production candidate: the notes emphasize stabilization of the multi-tenant boot process, an improved user resolver and middleware, and finalized Filament navigation and translations, with docs covering central/tenant database setup. Before we adopt: confirm Laravel/Filament version compatibility, review the tenant-boundary middleware and user resolver ourselves (that's the security-critical surface), check test coverage and the 1.x BC policy, confirm the license, and decide whether the bundled PayPalSettingsResource stays or gets swapped for our billing stack. Plan to pin the exact version, read the upstream diff rather than the release prose, and keep the integration behind a thin internal abstraction so a fork or replacement is a contained change.