Filament Form Builder Laravel Package

Technical Evaluation

Architecture fit

• The package is a Filament-native plugin, not a framework-agnostic form library. It only makes sense if the application already runs Filament panels (4.x/5.x). If your admin is custom Livewire, Nova, or plain Blade, the fit is effectively zero — you would be adopting an entire admin framework to get a form builder.
• It assumes a three-panel topology (FilamentFormBuilderPlugin for admin, FilamentFormBuilderGuestPlugin for unauthenticated users, FilamentFormBuilderFrontendPlugin for authenticated users). This is a genuine architectural constraint: public form delivery is implemented as Filament pages, not as a controller/view layer. Teams that want forms embedded in an existing marketing site or SPA need to evaluate the configurable routes (/forms/{form}, /entries/{entry}) and the blockRedirect Livewire prop as the only embedding surface.
• Data model is opinionated: forms, fields (sortable via spatie/eloquent-sortable), and entries (FilamentFormUser). Submissions are first-class Eloquent records with events — good for downstream automation, but it means your app inherits a schema you did not design.
• Multi-tenancy is first-class but configure-before-migrate. That is an architectural decision with real consequences: migrations conditionally add tenant columns, so tenancy is effectively a bootstrap-time choice, not a feature toggle.

Integration feasibility

• Install is VCS-only — not on Packagist. This is the single largest practical friction point. It requires a repositories entry in composer.json, a ^4.0 constraint against git tags, and acceptance that composer require/composer update semantics are weaker than a Packagist package (no metadata mirroring, no composer audit posture).
• Dependency surface is modest but non-trivial: maatwebsite/excel (pulls PhpSpreadsheet, which has its own PHP extension expectations — zip, gd, mbstring) and spatie/eloquent-sortable. Both are mainstream and well-maintained, which reduces risk considerably.
• Requirements (PHP 8.2+, Laravel 11+, Filament 4/5) are modern-only. Legacy apps are excluded, which is a clean, defensible line.
• Extension points exist and are documented: Laravel EntrySaved event, Livewire entrySaved listener, overridable ShowForm/ShowEntry page classes, overridable SetFormPanel middleware, configurable route URIs, configurable options editor. That is a reasonable seam set for a package of this size.
• Front-end CSS is not automatic: you must add ./vendor/tapp/**/*.blade.php to the Tailwind content array or Filament's classes get purged. Minor, but a classic day-one support ticket.

Technical risk

• Maturity risk (high). 14 stars, 0 dependents, single-org provenance. There is no independent evidence of production usage at scale. Score of 30.72 reflects this. Treat as "adopt with a fork plan," not "adopt and forget."
• Compatibility risk (medium-high). Filament is a fast-moving framework; the package already carries a Filament 3 → 4/5 split with a separate 1.x line. Every Filament major will likely require a package major and a migration on your side.
• Migration-ordering footgun (high). Enabling tenancy after migrations requires manual schema surgery. This must be an explicit checklist gate, not tribal knowledge.
• Silent-failure security surface (medium-high). Private entries depend on your app defining a policy with the exact method name and signature viewEntries(User $user, FilamentForm $form). If the method is missing, the package does not restrict entries or export. Fail-open authorization is a genuine security concern that needs a test, not a code review.
• Schema drift (medium). Forms can be edited after submissions exist; the locked flag exists precisely to prevent apples-to-oranges entries. It is opt-in per form and defaults to false, so integrity depends on operator discipline. The changelog history (v1.2 introducing locking, v1.21 adding a locked column) suggests this was retrofitted rather than designed in.
• Abuse protection (unknown, likely absent). Nothing in the README describes CAPTCHA, rate limiting, honeypot, or submission throttling for public/guest forms. Public write endpoints without abuse controls are a production blocker for most teams and should be assumed to be your responsibility.
• Bus factor (high). MIT license means you can fork and maintain; it does not mean you want to.

Key questions

1. Are we already on Filament 4.x or 5.x, and on Laravel 11+/PHP 8.2+? If not, this evaluation ends here.
2. Do we need public, unauthenticated form submission? If yes, what is our spam/rate-limiting story — package-provided or ours to build?
3. Is multi-tenancy in scope? If yes, is the tenant model already migrated and populated, and has the config-before-migrate ordering been validated on a scratch database?
4. Who owns the FilamentFormPolicy::viewEntries implementation and its test coverage? Without it, private entries are decorative.
5. What is the PII classification of collected responses? Where do entries live, what is retention, and do CSV exports leave our infrastructure?
6. Is Packagist publication on the maintainer's roadmap, or do we need an internal Composer mirror/vendor fork to satisfy supply-chain review?
7. What is our exit cost — how coupled would our app become to FilamentForm / FilamentFormUser models and the EntrySaved event?
8. Does the field-type coverage (including repeater and heading, added later) match our questionnaire complexity, and are file uploads supported?

Integration Approach

Stack fit

• Hard prerequisite: a Filament panel that already serves as the admin surface. Ideal stack is Laravel 11/12 + PHP 8.2+ + Filament 4/5 + a Filament-based admin, with a separate guest/app panel structure already established.
• Best fit is an internal-tools or SaaS admin context where the same team already owns panel configuration, policies, and Tailwind builds. Poor fit for content-marketing sites, SPA front ends, or teams without Filament fluency.
• Confirm the three-panel model maps to your reality. Many apps have one panel, not three; consolidating (admin-only, or admin + guest) is possible but requires deliberate config of guest-panel-id / app-panel-id.

Migration path

1. Pre-flight: pin the target Filament major; confirm it is the 4.x/5.x line and not the legacy 1.x branch.
2. Dependency: add the VCS repository, composer require tapp/filament-form-builder:"^4.0", and commit the lockfile. Pin an exact tag in production-critical environments rather than floating ^4.0.
3. Config first: publish filament-form-builder-config and make the tenancy decision before publishing migrations. This is the irreversible step.
4. Migrations: publish tags, review generated migrations (especially tenant column injection), then migrate. Do this on a scratch DB first to confirm column shape.
5. Panel registration: admin plugin → guest plugin (if public) → frontend plugin (if authenticated external users). Register incrementally and verify routes after each.
6. Assets: add ./vendor/tapp/**/*.blade.php to Tailwind content, rebuild.
7. Authorization: implement FilamentFormPolicy::viewEntries and the FilamentFormUser::view() delegation, with tests.
8. Automation: wire EntrySaved listeners for notifications/CRM sync; use the Livewire entrySaved event only where a parent component genuinely needs it (note: it dispatches the entry id, not the model).
9. Hardening: add rate limiting / bot protection in front of the public routes; queue CSV exports.
10. Instrumentation: seed a locked form with realistic field types (repeater, radio, select, heading) and run an end-to-end submission + export before declaring done.

Compatibility

• Filament major must match the package major (4.x/5.x ↔ 4.x). Do not attempt to run the 4.x package on Filament 3.
• maatwebsite/excel and PhpSpreadsheet bring extension requirements; verify against the production container image, not just local dev.
• Tailwind v3 vs v4 content/@source semantics differ — confirm which your build uses before copying the README snippet verbatim.
• Route URIs are configurable (filament-form-uri, filament-form-user-uri) — check for collisions with existing /forms/{slug} or /entries/{id} routes early.

Sequencing

• Week 0: stack confirmation + go/no-go on VCS-only install (supply-chain sign-off is usually the long pole).
• Week 1: scratch-environment install, tenancy decision frozen, migrations reviewed, single-panel smoke test.
• Week 2: panel topology, policy work, Tailwind, public-route hardening.
• Week 3: event integrations, export path, locked-form fixture, load/behavioral test.
• Defer: anything beyond core field types until the first real form ships.

Operational Impact

Maintenance

• VCS-installed dependency means upgrades are manual: bump the tag, read the changelog, retest. There is no Packagist release feed driving Dependabot/Renovate in the normal way.
• The changelog is granular and honest (typo fixes, radio-select bug, event payload change from model to id, copy-action fix), which is a positive maintenance signal — but the cadence of small patch releases implies active churn. Budget recurring upgrade time each Filament major.
• Adopt a fork-ready posture: mirror the repo internally, keep local patches in a thin overlay (custom page classes and config, not vendor edits), and document the fork procedure before you need it.

Support

• Single-vendor, small-community support. No SLA, no commercial backing evident, 14 stars. Realistic expectation: GitHub issues with best-effort response.
• The README is unusually complete for a package this size — install, tenancy, policies, events, config examples with closures. That materially reduces internal support load and is a genuine plus.
• Internal ownership should be explicit: one engineer who can read the package source and own the fork. Do not adopt if no one on the team is comfortable debugging Filament internals.

Scaling

• Entries are rows in a table. Expect growth to be the primary scaling concern: index by form and tenant, and plan archival/partitioning before volume matters.
• CSV export is the scaling cliff. maatwebsite/excel in-request will exhaust memory on large exports. Move to queued exports with notification-on-completion and stream downloads; consider disabling the bulk export action on large forms.
• Multi-tenancy scoping is query-level and automatic within panels, which scales adequately but puts pressure on tenant-indexed lookups — verify indexes match the tenancy columns chosen at migration time.
• Public form routes are unauthenticated by design; they scale with your web tier but invite traffic abuse. Load-test a public form before launch.

Failure modes

• Migration ordering: tenancy enabled after migrate → manual schema surgery and possible data rework. Highest-severity, lowest-visibility failure.
• Fail-open authorization: missing or misnamed viewEntries policy silently exposes private entries and enables export. Mitigate with an explicit test asserting a non-admin receives 403.
• Tailwind purge: missing vendor content path → broken styling in production only. Catch with a production build in CI, not dev.
• Filament major upgrade: admin panel breaks at the framework level, not the package level, making root-cause slower.
• Schema drift: form edited after submissions → incomparable historical entries. Mitigate by defaulting forms to locked once live, as policy rather than as hope.
• Public-route abuse: no documented spam controls → junk entries, polluted exports, storage growth, and potential cost if submissions trigger notifications/webhooks.
• Event payload confusion: the Livewire event sends the entry id, the Laravel event sends the entry model. Subtle, documented, and easy to get wrong in a listener.
• Tenant cascade deletion: deleting a tenant removes all its form data. Confirm this matches your data-retention policy before enabling tenancy, since it is destructive by design.

Ramp-up

• For a team already fluent in Filament: roughly 2–4 days to production-ready on a single panel, 1–2 weeks with multi-tenancy, public routes, policy work, and event integrations.
• For a team new to Filament: add 1–2 weeks of Filament fundamentals before this package is safe to operate. The package's complexity is largely Filament's complexity.
• Onboarding artifacts worth producing: a one-page install checklist with the tenancy gate called out, a policy test, and a "lock the form before launch" runbook. These three cover the majority of realistic incidents.
• Overall TPM recommendation: conditional pilot, not broad adoption. The capability-to-cost ratio is attractive for Filament shops with a low-stakes internal or public form need and an engineer willing to own a fork. It is not appropriate as a platform-level dependency without Packagist publication, independent usage evidence, and confirmed abuse protection.