Filament Form Builder Laravel Package

Product Decisions This Supports

Build vs. buy (well, "borrow"):

• The core decision this package informs is whether to hand-roll admin-configurable forms or adopt a free MIT plugin. Hand-rolling a visual form builder with field types, validation mapping, ordering, entry storage, export, and tenancy scoping is typically 3–6 weeks of engineering plus permanent maintenance. This package collapses that to a Composer install plus a migration — but only if you already run Filament.
• It is a borrow-not-buy decision: no license cost, but you inherit the maintenance risk of a 14-star package with 0 dependents. The real decision is "do we have an owner who can fork and patch this?" not "is it worth the money?"

Feature / roadmap decisions it unblocks:

• Ops-owned data collection: intake forms, internal request forms, feedback/survey forms, and lead capture that today are hard-coded Blade + FormRequest pairs. Ships a feature without a sprint.
• Self-serve form creation: non-engineers compose forms from native Filament fields with full Laravel validation rules. This shifts a recurring roadmap tax (every new form = a ticket) off engineering permanently. That is the single strongest product argument here.
• Multi-tenant portals / agency work: first-class tenancy with automatic scoping, tenant-specific URLs, and cascade deletion. If you sell per-tenant admin panels, this becomes a reusable primitive across clients.
• Longitudinal data integrity: "locked forms" (v1.2) is a genuine product feature — you can freeze a form so historical entries stay comparable. This supports anything research-flavored: NPS waves, recurring audits, compliance checklists.
• Data handoff as a product surface: CSV export means the output can be a deliverable to a client or an ops spreadsheet workflow, not just a database row.

Architecture / integration decisions:

• Three panel plugins (admin, guest, app) plus configurable routes, panel IDs, custom page classes, and custom middleware means the public-facing form URL is a configuration decision, not a fork. That keeps "should this form be public?" a per-form toggle (permit_guest_entries) rather than an engineering project.
• Events (EntrySaved Laravel event + entrySaved Livewire event) are the extension seam for everything the package doesn't do: notifications, CRM sync, downstream workflows. This is what makes it a component rather than a dead end.
• Scope boundary to set explicitly: no documented conditional logic / branching, no partial submissions, no built-in anti-spam or rate limiting, CSV-only reporting. Decide up front whether you need those; if yes, this is a foundation you extend, not a finished product.

When to Consider This Package

Adopt when most of these are true:

• You are already on Filament 4.x/5.x, Laravel 11+, PHP 8.2+ and have an admin panel shipping today. Outside that stack the integration cost flips the math.
• Forms are a supporting capability, not your product. If forms-as-a-feature is a revenue driver, you want control you don't get from a 14-star dependency.
• You have a named engineering owner willing to vendor/fork it. Non-negotiable given: not on Packagist (VCS repository install), single-org maintainer (TappNetwork), 0 dependents, and low adoption signal.
• Your volume and risk profile tolerate it: internal ops forms, authenticated user forms, or low-stakes public forms where you can add your own rate limiting and spam controls.
• You want multi-tenancy — and you will configure tenancy before publishing/running migrations. Enabling it later requires manual schema surgery; this is the highest-probability operational footgun in the package.
• You are comfortable that private-entry access control is enforced through your app's FilamentFormPolicy::viewEntries() with an exact method name and signature. The package fails open (no policy method = no restriction), so access control is your responsibility, not a shipped default.

Look elsewhere when any of these are true:

• You need conditional logic, multi-step wizards, partial saves, or scoring/calculation — the README doesn't claim these and the changelog doesn't suggest them.
• You need analytics, dashboards, or reporting beyond CSV export.
• Compliance-heavy or high-PII public collection where you need documented retention, audit trails, consent capture, or a vendor SLA. The MIT license is fine; the support posture isn't.
• Your supply chain requires Packagist-registered, security-scanned, semver-stable dependencies. A VCS install pinned to ^4.0 with no Packagist presence will fail most enterprise dependency governance reviews.
• You are on Laravel 10 / PHP 8.1 or Filament 3 (that path is the unsupported 1.x branch — a dead end, not a migration story).
• You need CSV import, webhooks with retries, or field-type extensibility as day-one requirements; you'll be writing all of it.

Evaluation flags to disclose internally:

• Maturity score 30.72 / opportunity 31.51 with 0 dependents and 14 stars is a "pilot, don't platform" signal.
• maatwebsite/excel is a heavyweight transitive dependency pulled in solely for CSV export — worth knowing, since it affects your audit surface.
• The changelog shows a healthy iterative cadence (locking, copy action, repeater/heading fields, radio bug fixes) but also repeated small bugfix releases — consistent with a young package, not a hardened one.
• Confirm the release/versioning timeline internally before committing; treat the package as beta-grade regardless of the 4.x version number.

How to Pitch It (Stakeholders)

For executives — the one-paragraph version: Every new form request today is an engineering ticket. This free, MIT-licensed plugin lets our operations team build and launch data-collection forms from the admin panel we already run, with the same validation rules we'd write by hand, and export the responses to CSV. It removes a recurring, low-value engineering queue item and turns form creation into a self-serve capability. Cost is zero in license fees and roughly a day of setup. The risk is maintenance: it's a young package from a small maintainer with little adoption, so we treat it as a pilot on internal, low-risk forms first, assign one engineer as owner, and keep the exit door open — our data lives in our own database, so walking away means keeping the tables and writing a small form UI, not migrating off a vendor.

For engineering — the honest technical summary:

• What it is: a Filament plugin adding a FilamentFormResource (admin), plus guest and app panel plugins for public/authenticated form rendering. Forms are composed of native Filament field components, so behavior and styling match the rest of the panel.
• Why it fits: Laravel validation rules throughout, spatie/eloquent-sortable for field ordering, an EntrySaved Laravel event as the integration hook, blockRedirect for embedding the form Livewire component inside another page, and per-form locking for data integrity.
• What you must own: the tenancy config must be set before migrations run; private entries depend on a correctly named policy method and fail open if absent; Tailwind content glob for ./vendor/tapp/**/*.blade.php; and our own spam/rate limiting for any public form.
• Supply chain: install via VCS repository, pin the constraint, mirror the repo internally, and designate a fork owner. Do not let this become an unpinned dev-main dependency.
• Recommendation: pilot on 2–3 internal forms, measure time-to-launch versus hand-coding, and re-evaluate before using it for anything customer-facing or compliance-relevant.