Filament Studio Laravel Package

Technical Evaluation

Architecture fit

• The package is an EAV (Entity-Attribute-Value) layer rendered through Filament resources: collections define a schema, fields define attributes, and records hold values in a shared store. As a TPM, treat this as a capability decision, not a component decision — it determines whether we can offer tenant-defined objects without per-customer migrations.
• Sound fit for sparse, user-defined, tenant-scoped attributes: internal tooling, back-office operations, CMS-style content, configurable intake forms, CRM-style custom fields. Poor fit for core domain entities that drive joins, aggregation, reporting, or high-volume transactions.
• Recommended posture: bound it as a sidecar — relational core table plus an EAV extension for tenant-defined attributes. Using it as the primary persistence model for product-critical data converts a speed advantage into a long-term reporting and integrity liability.
• The 33 field types plus dashboards signal a no-code admin value proposition aimed at ops teams and agencies. Confirm that is the audience we are serving; if the buyer is a developer, the abstraction may cost more than it saves.
• Versioning and multi-tenancy are the highest-consequence claims and are the least specified in available material. They touch audit/compliance and tenant isolation respectively — both need proof, not documentation review.

Integration feasibility

• Install surface is conventional for the ecosystem: Composer, Laravel auto-discovery, publishable config and migrations, plugin registration in a PanelProvider. Low friction if we are already on Filament.
• The gating question is the Filament major / Laravel / PHP compatibility matrix. Filament has broken across majors; an unverified matrix is the most probable cause of a failed spike. This is the first thing to pin down.
• Database portability matters because EAV implementations lean on JSON columns and driver-specific indexing. Verify on our production driver, not the package's test suite.
• The surface is UI-first. If we need headless consumption — APIs, imports, background jobs, reporting — confirm a first-class query/Eloquent/event API exists. This single answer decides whether the package is infrastructure or only an admin tool, and it changes the business case materially.

Technical risk

• Adoption risk: high. ~61 stars, 0 dependents — effectively no production evidence in the wild. We would absorb early-adopter defect cost.
• Bus factor: high. Individual maintainer, no evident sponsoring organization, no security policy or succession plan. MIT permits forking, but forking is a staffing commitment, not a mitigation.
• Release hygiene: v1.8.0 notes are a changelog link with no substance, and the recorded release date (2026-09-09) is anomalous. Treat release metadata as unverified and audit commits, tags, and CI status before relying on it.
• EAV integrity risk: schema edits against live data are the classic failure mode — renames, type changes, deletions orphaning values. Confirm schema mutations are transactional, blocked or migrated when records exist, and previewable.
• Tenant isolation risk: if tenants share EAV tables behind a tenant_id discriminator, one missing global scope is a cross-tenant leak. Require enforcement at the query layer and a test that proves it.
• Upgrade coupling: a package that owns Filament resource definitions is bound to Filament internals. Every Filament upgrade becomes a joint upgrade. Pin versions; track the upstream compatibility window.

Key questions

1. What is the tested Filament / Laravel / PHP / database matrix, and the stated upgrade policy per Filament major?
2. Is tenant scoping enforced at the Eloquent/query layer, and is there an isolation test we can run ourselves?
3. What is the storage shape — typed columns, JSON, or single value column — and how are indexes defined for filter and sort?
4. Is there a programmatic API independent of the Filament UI (models, query builders, events, jobs)?
5. What does "versioning" cover: per-record audit history, per-schema versioning, or both? Can we diff and restore?
6. Are schema mutations transactional and safe with existing records? Is there a dry-run path?
7. What is the CI matrix, coverage, and static-analysis posture? Is there a security disclosure process?
8. Is there an export path from EAV into flat tables or relational models — i.e., what is our exit?
9. What is the maintainer's demonstrated release cadence and responsiveness over the last 12 months?
10. Are licensing, CLA, or contributor terms compatible with an internal fork?

Integration Approach

Stack fit

• Best fit: a Laravel + Filament monolith with an existing admin panel and a genuine slice of tenant-configurable data. The package then adds capability rather than a platform.
• Poor fit: API-first or headless services, event-driven architectures, or any context where the data is consumed by systems that do not speak Filament. EAV behind a UI-only package becomes a reporting bottleneck with no clean escape.
• If the panel already uses Filament's native multi-tenancy (HasTenants, tenant-scoped panels), confirm the package participates in that lifecycle. Two parallel tenancy mechanisms in one app is a defect generator, not a feature.

Migration path

• Adopt incrementally: install, publish config and migrations into our own migration set (never run vendor migrations unmodified in production), and register the plugin in a single non-critical panel first.
• Fix a table-prefix/namespace convention before the first migration so the package's tables are identifiable and can be relocated or dropped cleanly.
• Do not migrate existing relational data into EAV. Introduce it only for net-new tenant-defined attributes. Relational-to-EAV backfill is a one-way door with poor query characteristics on the far side.

Compatibility

• Pin exact versions and lock the Filament major. Treat a Filament upgrade and a package upgrade as one change unit with a joint regression suite.
• Run the spike against our production driver and our real panel configuration (tenancy on/off, policies, roles). SQLite success locally is not evidence.
• Check Livewire/Alpine/Tailwind asset-build compatibility if the package ships views or assets; asset-publish conflicts are a common hidden cost that lands on the frontend team.

Sequencing

1. Spike + ADR (1 sprint). Verify the matrix, run the package's tests inside our CI, prove tenant isolation with a failing-then-passing test, document the EAV query model. Output: go/no-go ADR with a named owner.
2. Proof of concept (2–3 weeks). One internal, low-blast-radius collection with 5–8 field types, including one filter/sort-heavy table and one dashboard. Measure query counts and page latency against an agreed threshold.
3. Hardening. Wrap the package behind our own repository/service boundary so call sites never depend on vendor classes directly. Add integration tests for schema mutation, isolation, and versioning. Pin versions; stand up a private mirror or fork decision point.
4. Pilot. One tenant or one internal team, with an explicit rollback plan and a documented exit path (export to flat tables, drop EAV tables).
5. Expand or exit. Gate expansion on measured performance and on maintainer responsiveness during the pilot — not on the spike's optimism.

Operational Impact

Maintenance

• Budget internal ownership regardless of upstream health. Realistic steady state is roughly 10–20% of a developer for version tracking, Filament upgrade coupling, and bug triage. If we fork, that rises and becomes non-negotiable.
• Maintain our own changelog and compatibility matrix; upstream release notes are too thin to be our record. Review upstream commits before each upgrade rather than trusting semver.
• Keep our own migration copies under version control. Vendor-published migrations we do not control are both a supply-chain and a rollback hazard.

Support

• MIT, no warranty, no SLA. Support is GitHub issues at the maintainer's discretion, with no evident commercial backing, so no escalation path exists.
• Name an internal owner and pre-agree the escalation rule: if an upstream defect blocks a release, we patch locally and carry the patch. Decide before adoption whether we are willing to fork; if not, cap the blast radius accordingly.
• Require a security review before production: dependency audit, review of raw query construction, and confirmation that authorization is server-side rather than implied by Filament UI visibility.

Scaling

• EAV scales acceptably for reads scoped to a single entity and modest record counts. It degrades on cross-entity aggregation, multi-attribute sorting, and reporting joins — precisely the queries that appear once the feature succeeds.
• Define numeric thresholds up front (record counts, concurrent editors, p95 page latency, dashboard query budget) and state what happens at breach: denormalized read model, materialized reporting table, or exit.
• Watch schema cardinality: many collections × many fields inflates join counts and index pressure per query. Cap fields per collection and validate against a realistic tenant profile, not a demo one.

Failure modes

• Cross-tenant leak via a missed global scope — highest severity, lowest detectability. Mitigate with a query-layer isolation test in CI and a periodic audit job.
• Schema drift corrupting live values on rename/type-change/delete. Mitigate with transactional mutations and a preview path; block destructive changes when records exist until a migration is authored.
• Filament major upgrade breaking the package and stranding the admin panel. Mitigate with version pinning and a joint regression suite.
• Maintainer abandonment. Mitigate with an exit path (export to flat tables), a mirrored fork, and a documented decision date to reassess.
• Silent EAV performance cliff as data grows. Mitigate with query-count and latency budgets in the PoC that persist as production alerts.

Ramp-up

• Low for a team already fluent in Filament — days, not weeks, to a working panel. The real cost is conceptual: engineers must internalize that EAV attributes are not columns, that validation lives in metadata, and that "just add a field" now has data-migration semantics.
• Plan a short enablement pass: the EAV query model, the schema-mutation safety rules, the tenancy contract, and the wrapper boundary so no one calls vendor classes directly.
• Train support and ops on the rollback and export procedures before the pilot, not after. The package's value proposition is speed; the operational cost is that speed is repaid later, and the team should know where.