Livewire Forms Laravel Package

Product Decisions This Supports

• Build vs. buy for form infrastructure. If we're on Statamic 5 + Laravel Livewire, this replaces weeks of custom Livewire form components, AJAX submission plumbing, and a client-side validation library with a composer dependency. The decision to evaluate is "buy and extend" vs. "build bespoke," and the package's extensibility (custom field models, hooks, themes) means we can buy the 80% and own only the differentiators.
• Single source of truth for validation. Validation rules live in Statamic form blueprints and are reused server-side by Livewire — no duplicated rule sets drifting between front end and back end. This is a defect-reduction argument, not just a velocity argument: fewer places for "the client said it was valid but the server rejected it" bugs.
• Roadmap acceleration for form-heavy features. Contact/lead capture, quote requests, surveys, gated content, newsletter signups, and event registration can all ship on the same blueprint-driven primitive. That shortens the estimate for any upcoming form workstream and lets us sequence more conversion features per quarter.
• Editorial ownership of forms. Because blueprints are authored in the Statamic control panel, content/marketing can add fields, change labels, and set display conditions without an engineering ticket. This is a concrete operational-cost decision (fewer handoffs, faster copy changes) that should be weighed against governance risk of editors changing schema.
• Internationalization / multi-site. Built-in translation of labels, instructions, and placeholders means multi-market launches don't require a fork of the form layer. If international expansion is on the roadmap, this de-risks it.
• Anti-spam baseline. reCAPTCHA v2 plus honeypot is included, deferring a decision to buy a dedicated spam service or build rate-limiting logic. Low cost, but note reCAPTCHA v2 is the older checkbox/token flow — if we want invisible v3/Enterprise, this does not cover it.
• Integration surface for downstream systems. The form-submitted Livewire event, the Statamic FormSubmitted event, and the formSubmitted hook give us defined seams for CRM sync, marketing automation, and notification routing — that's where the real product value beyond "the form renders" gets built, and it determines whether we need a middleware service later.
• Conditional logic without custom JS. Display conditions defined in blueprints support progressive disclosure (qualifying questions, branching intake) without bespoke Alpine/JS work — useful for lead qualification and reducing form abandonment.

When to Consider This Package

Adopt when:

• We are already committed to Statamic 5+ and Livewire — this is an addon, not a standalone library, so it's a near-zero marginal decision on an existing stack.
• Forms are becoming a recurring product surface (multiple forms, multiple sites, recurring field changes) rather than a one-off contact page.
• We want real-time, per-field validation feedback and are willing to accept Livewire round-trips as the mechanism.
• The design system is or can be Tailwind + @tailwindcss/forms based; otherwise we inherit the cost of rewriting the provided views.
• We need editor-facing form definition more than we need a marketing-grade drag-and-drop form builder.

Look elsewhere / proceed with caution when:

• License is unresolved. The repo reports NOASSERTION, which is a hard stop for procurement and legal until we confirm the actual terms. This must be cleared before any production dependency, regardless of technical fit.
• Ecosystem validation is thin. 29 stars, 0 dependents, and a modest opportunity score mean few public production references and limited community troubleshooting. Treat it as a small-audience package, not a de facto standard.
• Single-maintainer and view-churn risk. The README explicitly warns that future releases will likely introduce breaking changes to our views, requiring manual updates. That's a recurring maintenance tax we must budget for and pin versions against.
• We need capability beyond blueprints. Complex multi-step wizards with persistence, payment/checkout flows, advanced file-upload pipelines at scale, or heavy client-side interactivity are outside the sweet spot — building on Livewire directly may be cleaner than fighting the abstraction.
• We require vendor support, SLAs, or a security-reviewed dependency. No commercial backing is evident; if the form handles regulated or high-value data, our security review bar likely exceeds what an unmaintained-ish addon can satisfy without a fork.
• We aren't on Statamic. There is no portability story; this is a lock-in commitment to the Statamic + Livewire pairing.

Recommended posture: time-boxed spike on one real, low-risk form (e.g., a contact or lead form), with a wrapper component around the form layer so we retain swap-out optionality. Gate production adoption on license clearance and a maintenance-ownership decision.

How to Pitch It (Stakeholders)

For executives (one paragraph): We're evaluating a small open-source addon that lets our existing Statamic content system define forms once and have them render as real-time, validated Livewire forms. The business case is speed and consistency: it removes duplicated validation logic, lets marketing edit forms without engineering tickets, and gives us spam protection, multi-language support, and conditional logic out of the box — so form-driven features like lead capture and registration ship faster with fewer defects. It's low-cost and narrowly scoped, with two caveats we're actively managing: the license needs legal confirmation, and because it's a small single-maintainer project we'll pin versions and keep an abstraction layer so we're never locked in.

For engineering (the honest version):

• We get blueprint-as-schema, server-authoritative validation, and a clean set of extension points: custom field models (swap a fieldtype's model by class or by field handle), mountedFields and formSubmitted hooks, and both Livewire and Statamic FormSubmitted events for downstream integrations.
• Artisan scaffolding (livewire-forms:setup, :view, :theme, :component) plus view/theme/component autoloading by form handle means the default path is fast and the escape hatch to fully custom markup (@formField, @formView, custom components) exists.
• Costs to accept explicitly: Tailwind + forms plugin is assumed for the shipped views; manual JS bundling is required if we bundle Livewire ourselves; and the maintainer has flagged that view-level breaking changes are expected in future releases — so views are ours to own and upgrade, not fire-and-forget.
• Risk mitigations: pin the Composer version, vendor/lock the published views, wrap rendering behind our own component boundary, and treat the license question as a release blocker until resolved.

Bottom line for the go/no-go: technically a strong fit for our stack with real velocity and consistency upside; the decision hinges on license clearance and our appetite for maintaining a small, opinionated dependency. Recommend a scoped pilot, not a platform-wide commitment.