Filament Saas Laravel Package

Technical Evaluation

What this actually is. Despite the Composer packaging, this is a SaaS starter kit / application skeleton, not a consumable library. The README is the unedited Spatie package template — the description literally reads "This is where your description should go," usage is TODO, the published config is an empty return [];, and the credits still point at Spatie and their postcard wall. The real content is an opinionated Filament admin stack: roles/permissions (filament-shield), exception tracking, activity logging, command palette, banner, picker, phone input, rich text editor, date-range filters, translations, a settings/features abstraction, a WhatsApp widget, and an OpenAI integration implied by openai-php/laravel.

Architecture fit. Poor-to-moderate as a dependency, moderate as a reference implementation. Two structural mismatches:

1. Distribution model vs. artifact type. A starter kit is consumed by fork-and-prune; it is not consumed by composer require. Installing skeleton code into vendor/ means you own published migrations/views that will drift from upstream, while the parts you'd actually want to override (panels, resources, policies) live in a package you can't cleanly subclass. There are no documented contracts, service-provider extension points, or config knobs to justify vendor isolation.
2. Namespace instability. The changelog shows Change all namespace (v1.9.0) and Change namespace case (v1.10.0) as shipping releases. That's a class of change that invalidates published views, cached config, and any app code referencing these classes — and it happened twice inside a beta line.

Integration feasibility. Mechanically trivial (three vendor:publish tags and migrate), operationally blind: no configuration surface, no tenancy documentation, no upgrade guide. The "settings and features epic" and tenant work are announced in release titles only. One release note (v1.7.0-beta, "Fix tenant things and names") links to octo-core, a different repository — a provenance and traceability gap worth noting when assessing how the code is actually maintained.

Technical risk.

• No stable release. 1.0.0 is the only non-beta; the line runs to v1.19.0-beta. Filament 4 was adopted in v1.15.0-beta with no compat shim for Filament 3. Beta-forever means no semver guarantee, and the version you pin is the version you support.
• Unvalidated adoption. 19 stars, 0 dependents. There is no production corpus to surface tenancy or upgrade bugs before you hit them.
• Bus factor of one. Single maintainer (a21ns1g4ts); no commercial support, no SLA, sparse security policy (README links the template boilerplate).
• Dependency fan-out. ~15 third-party Filament plugins, several themselves pre-1.0 (kenepa/banner ^0.1.0, icetalker/filament-picker ^0.5.0, z3d0x/filament-logger ^0.8). Every Filament major forces a coordinated multi-package upgrade, and any one abandoned plugin can block a framework security patch. The release history is dominated by Dependabot bumps, which tells you where maintenance effort goes.
• Multi-tenant isolation is the top-severity, lowest-detectability risk. Tenant scoping is the whole point of the package and is entirely undocumented; a missing global scope is a silent data-leak class of bug.
• Third-party service coupling. OpenAI and WhatsApp features carry credential management, per-tenant cost attribution, and data-residency implications — none documented. Absent keys likely degrade silently or error at render.
• Verification is unproven. Tests and Codecov badges exist, but no coverage figure or CI status is provided in the evidence; treat as unverified.
• Metadata anomaly. The listed last release date is future-dated; discount release-cadence signals derived from it.

Key questions to resolve before any commitment.

1. Is this intended as a package or a repository template? (The README says package; the content says template.)
2. What is the tenancy model — single database with tenant_id scoping, or database-per-tenant — and where is it enforced?
3. What is the supported upgrade path between betas, and is there an intent to ship a stable 1.x?
4. What does this give us beyond a fresh Filament 4 panel plus the same plugin list? Itemize the actual delta.
5. Which features require paid external services, and what happens when they're unconfigured?
6. Who responds to security reports, and on what timeline?
7. Are the test suite and CI actually green at our target tag, and what do they cover?

Verdict: evaluate as a design reference, not as a dependency. The value is in someone else's opinions about a Filament SaaS admin; the risk is inheriting an unmaintained, beta, single-maintainer skeleton with an undocumented tenancy core.

Integration Approach

Stack fit. Only viable if the organization is already committed to Laravel + Filament v4 for admin surfaces (Livewire/Tailwind front end). It is a non-starter for API-first, Inertia/Vue, or Nova-backed teams — there is nothing to extract. Assume PHP 8.2+, Filament 4.x, Livewire 3.

Recommended migration path — fork and prune, not composer require.

• Pin a single tag and clone it. Read the source; do not read the docs (there are none). Snapshot the tag SHA in your ADR.
• Copy into a fresh Laravel + Filament 4 application, taking only: auth/panel scaffolding, tenant model and middleware, policies/Shield config, settings/features abstraction, and the migrations you have reviewed line by line.
• Prune aggressively. Drop spotlight, banner, picker, tinyeditor, WhatsApp, and the OpenAI wiring unless a roadmap item requires them. Cutting five pre-1.0 plugins is the single highest-leverage risk reduction available here.
• Treat upstream as read-only reference afterward; cherry-pick selectively rather than merging.

Fallback path — Composer install into greenfield (only if the team insists on dependency-style upgrades): pin an exact version, commit the lockfile, publish all three tags, review migrations for tenant columns and FK ordering before running, and schema-dump immediately after. Accept that published views and migrations become app-owned and will conflict on future publishes.

Compatibility checks before anything else.

• Confirm each plugin has a Filament 4-compatible release (Shield 4.x in particular; older tutorials will mislead).
• Run composer why-not against any existing panel if retrofitting rather than greenfield.
• Validate the database driver assumption — JSON settings columns and tenancy behave differently on MySQL vs. PostgreSQL.
• Check that spatie/laravel-data ^4 and symfony/intl ^7 align with the rest of the platform.

Sequencing.

1. Spike (1–2 days, timeboxed). Fresh app, install at the pinned tag, boot the panel, create a tenant and a user, exercise settings/features, toggle each optional plugin. Log every failure and every undocumented assumption — this log becomes your internal documentation.
2. Dependency audit. Generate the full composer show --tree; flag every pre-1.0 package and every package with no release in the trailing twelve months. Decide keep/drop per plugin against the roadmap.
3. Fork and prune. Build the owned baseline: auth, tenancy, roles, settings. Strip demo widgets and unneeded integrations.
4. Tenancy hardening before feature work. Write cross-tenant isolation tests (a user from tenant A must not read tenant B's records through any resource, relation manager, global search, export, or API route). This is the gate.
5. CI baseline. Tests, static analysis, migration dry-run against a clean database, lockfile-diff policy on PRs, and a rule that no beta upgrade merges without the isolation suite passing.
6. Only then, feature work on your own schema.

Operational Impact

Maintenance. You inherit the entire plugin graph, not just this package. Every Filament major (v3→v4 already happened mid-beta here) is a coordinated upgrade across roughly fifteen packages you don't control — budget a recurring upgrade sprint per Filament major, plus monthly Dependabot triage. Because published views and migrations become app-owned, expect recurring merge friction on any attempt to track upstream; the practical posture is a hard fork with periodic manual diff review. Namespace churn in the beta line means composer update is a deployable incident until you stop tracking upstream.

Support. No commercial support, one maintainer, all-betas, no SLA, no documented security response. Assign an explicit internal code owner for the panel and for tenancy — assume you fix your own breakage and that upstream issue turnaround is best-effort. Write a runbook during the spike; it is the only documentation that will exist.

Scaling. Panel-side scaling is conventional Laravel: queue workers for exports and notifications, Redis for sessions/cache, read replicas for reporting. Watch these specifically:

• Filament tables over large tenant tables — index tenant columns, audit relation managers for N+1.
• Settings stored as per-tenant JSON — cache them; don't re-read per request.
• Global search (spotlight, if kept) across many tenants is a cheap denial-of-service on your database.
• Log and exception tables grow unbounded — set retention and prune jobs on day one.
• File uploads to object storage, not local disk, before the second tenant arrives.

If multi-tenancy is in scope, decide single-DB tenant_id scoping versus database-per-tenant now; retrofitting after feature work is a multi-sprint project, and Filament's tenancy configuration is opinionated enough that switching later means rewriting resources.

Failure modes to instrument for.

Ramp-up. Days for a developer already fluent in Filament v4; one to two weeks to first productive feature for a mid-level Laravel developer without Filament exposure. The tax is not the framework — it's that there is no usage documentation whatsoever, so every convention (settings/features abstraction, tenancy wiring, Shield policy mapping) must be reverse-engineered from source and then written down. Plan the spike to produce three artifacts that don't exist upstream: an ADR recording why this was chosen over a clean Filament panel, a tenancy/isolation test suite, and a one-page operator runbook. If those artifacts can't be produced in the spike, that is itself the answer.