Livewire Form Builder Laravel Package

Product Decisions This Supports

• Build vs. buy for form capture. A dynamic form builder is one of those features that looks like a two-week ticket and turns into a quarter: schema persistence, field-type rendering, validation mapping, submission storage, and an admin UI. This package collapses the builder-and-render layer into a Composer dependency, which lets you redirect engineering time toward the workflow that consumes the form data rather than the plumbing that collects it.
• Field-type coverage as a proxy for use-case coverage. 0.7.0 adds file upload, radio, and checkbox — the three biggest gaps in a form builder's "can we actually ship this?" checklist. Concretely, this release moves the package from "text and selects only" territory into:
  • File upload → document collection, onboarding/KYC packets, support attachments, resume intake, proof-of-delivery photos.
  • Radio → mutually exclusive choices where a dropdown is a UX downgrade: plan selection, consent/acknowledgement, single-answer survey items.
  • Checkbox → multi-select preferences, notification opt-ins, terms acceptance, feature-interest capture in waitlist or beta-signup flows.
• Roadmap signal. Adding three field types in one minor release on a 0.x package is a healthy velocity signal, but it is also a signal about maturity: the maintainer is still filling out the core field surface. Treat field-type parity as an adoption gate — the package is now plausibly sufficient for internal tools and admin-configured forms, but not yet for a customer-facing form product where you need conditional logic, multi-step wizards, and advanced validation authoring.
• Prioritization lever. If your backlog has "let ops/marketing build their own forms without engineering," this is the cheapest credible path to test that thesis. Ship an internal pilot against one real workflow (e.g. a document-upload intake form) and measure whether non-engineers actually self-serve. That experiment is cheap now in a way it wasn't at 0.6.1.
• Risk decision this forces. Pre-1.0 software means the schema and component APIs can change under you. That is a real decision, not a footnote: adopting now buys speed at the cost of a future migration, and the call should be made explicitly rather than discovered during an upgrade.

When to Consider This Package

Consider it when:

• You are on Laravel + Livewire already. This is not framework-agnostic; the value proposition is tightly coupled to the Livewire rendering model, and the cost of adoption outside that stack is prohibitive.
• You need admin- or user-defined forms whose shape is unknown at build time — internal request forms, intake questionnaires, surveys, onboarding packets — rather than one or two fixed, hand-coded forms. Hand-coding two forms is cheaper than any dependency.
• Your current field requirements fall inside the supported set: text inputs, selects, radio, checkbox, and file upload. If you need conditional/branching logic, calculated fields, repeatable field groups, multi-page wizards, or a signature pad, verify support before committing — the release notes don't claim these.
• You can absorb pre-1.0 churn. Pin the version, keep the builder schema in your own database with a migration path in mind, and isolate the package behind a thin internal abstraction so a swap or a fork stays possible.
• The form is internal-facing or low-blast-radius. File upload arriving in a 0.x release is a prompt to verify the details that matter for production: where files are stored, size and MIME validation defaults, and whether uploads are scoped per-tenant.

Look elsewhere when:

• You need a battle-tested, contractually stable form layer with a support commitment. A single-maintainer 0.x package with a small contributor base is a dependency risk you should price in; check issue responsiveness, test coverage, and whether the repo shows signs of sustained investment.
• You require accessibility compliance (WCAG for public-sector or enterprise procurement), i18n/localization, or deep theming control. These are rarely first-class in young form builders and are expensive to retrofit.
• Your forms need complex validation authoring by end users — regex rules, cross-field dependencies, custom rule objects. Confirm what's expressible before promising it to stakeholders.
• You need submission storage, export, and analytics out of the box. A builder that renders forms is not the same product as a form platform; be explicit about which one you're buying.
• The form is customer-facing and high-stakes (payments, regulated data). Wait for 1.0 or budget for a fork you own.

How to Pitch It (Stakeholders)

To executives: This is a small, free open-source component that lets non-engineers assemble forms — intake, onboarding, surveys, document collection — without filing engineering tickets. The latest release (0.7.0) adds file upload, radio buttons, and checkboxes, which is the difference between "demo-quality" and "covers most of our internal forms." The pitch is not the library; it's the operating model: ops builds the form, engineering stops being a bottleneck for data collection. The honest caveat is maturity — it's a pre-1.0 project from a single maintainer, so I'd frame this as a bounded pilot on one internal workflow with a pin-and-isolate strategy, not a platform standard. Cost of trying is days; cost of building equivalent in-house is a quarter.

To engineering: Adopt behind a thin internal abstraction — our own form-schema model and a renderer that delegates to the package — so upgrading or replacing it is a contained change, not a rewrite. Pin to 0.7.0, not a range. Before the pilot, verify the three things this release makes newly load-bearing: file storage configuration and validation defaults (disk, size, MIME, tenant scoping), how radio/checkbox values are persisted and later read back, and whether the 0.6.x → 0.7.0 upgrade touches any stored schema. Watch the changelog for the 1.0 milestone; that's the natural point to reassess whether we keep the wrapper or drop it.

To the pilot's business owner: Success looks like one real workflow — say, a document-upload intake form — running in production for a month with the form owned by the business team, zero engineering tickets for field changes, and no data-integrity issues on uploads. If field-type gaps (branching logic, multi-step) block the workflow, that's a finding worth knowing now, cheaply.