Forms Laravel Package

Product Decisions This Supports

• Build vs. buy for internal/back-office data capture: laravel-enso/forms is a template-driven form builder — form definitions live in the database (JSON templates) and render through a consistent UI with server-side validation. That directly supports the recurring "we need another admin CRUD form" request without a bespoke sprint each time.
• Ops-configurable forms without deploys: the strongest product argument is that non-engineering staff can add fields, reorder sections, or add validation rules to an existing form and ship it same-day. This reduces change-request latency on intake forms (vendor onboarding, KYC, lead qualification, internal requests) and shifts low-risk iteration off the engineering backlog.
• Standardizing form UX and validation: adopting one builder forces a single convention for field types, error messaging, and persistence, which is cheaper than reconciling five homegrown Blade forms with divergent validation.
• Roadmap sequencing: if admin-surface area is expanding (more entities, more workflows, tenant-specific fields), a form builder is an infrastructure investment that pays back across the next N features. If you only have two or three static forms on the roadmap, it is over-engineering.
• Multi-tenant / per-client customization: dynamic templates are a viable answer to "Enterprise customer B needs three extra fields." This is a product-scoping decision — configurable fields vs. forked code — and the package supports taking the configurable route.
• Not a customer-facing product decision: this is an internal/administrative tool. Do not treat it as the basis for a customer-facing form product without a separate review of the front-end stack and UX.

When to Consider This Package

Consider it when:

• You are already building on, or committing to, the Laravel Enso ecosystem. This is close to a hard prerequisite — the package depends on Enso core primitives (structure, resources, menu/permissions, its Vue front-end conventions) and is not a drop-in for a vanilla Laravel app.
• Your team is Laravel/PHP-fluent and wants form definitions managed as data, not code.
• The forms in question are internal admin/back-office, where a conventional admin UI is acceptable and pixel-level design control is not required.
• You need many similar forms with a small, stable field vocabulary (text, select, date, file, relationship selects).
• You can accept the maintenance burden yourself — MIT license means you own fork risk, security patching, and Laravel major-version upgrades.

Look elsewhere when:

• You are not on Enso. Retrofitting Enso to use this package means adopting an entire opinionated admin framework; the integration cost dwarfs the form-builder benefit.
• Community size and longevity matter. ~123 stars with a single-primary-maintainer pattern is a real sustainability signal. If this form layer is on a critical path with a 3–5 year horizon, prefer Filament, Laravel Nova, or Livewire-based builders with larger contributor bases, or a hosted form service (Form.io, Tally, Typeform) for anything customer-facing.
• You need customer-facing, brand-controlled, accessible, or high-conversion forms. Front-end control and analytics/experimentation hooks will be constrained; the builder's value is speed, not experience quality.
• Front-end stack is React/Next or a modern Vue 3 SPA. Enso's UI layer is dated relative to current Vue/Inertia conventions; expect friction and eventual rewrite pressure.
• Compliance-heavy forms (regulated data capture with audit trails, e-signature, retention policy) — dynamic schema is a liability unless you own the audit and versioning layer.
• You only need a handful of static forms. Hand-written Laravel form requests plus Blade/Livewire is less machinery and fewer unknowns.

How to Pitch It (Stakeholders)

For executives — one paragraph: Admin forms are a quiet but persistent tax: every new intake form, approval request, or onboarding checklist costs engineering days, and small field changes cost more. laravel-enso/forms makes forms configurable data rather than code, so operations can add fields and adjust validation themselves, and engineering builds the form once. The expected return is fewer change requests hitting the sprint and faster turnaround on internal tooling. The caveats are honest ones: it is a small, MIT-licensed component of a specific Laravel admin framework, so it is a fit only if we are already — or are willing to become — an Enso shop. It is an internal-tooling efficiency play, not a customer-facing product bet.

For engineering — the framing:

• Templated form definitions persisted in the DB and rendered through Enso's conventions; validation and persistence are handled for us, which is where most of the bug surface in hand-rolled forms lives.
• Trade-off is architectural: adopting it deepens Enso coupling (structure, permissions, front-end stack) and hands us the upgrade path for Laravel majors and the Vue layer.
• Recommendation: timebox a spike against two real forms we already have, measure the delta against our current Blade/Livewire approach, and confirm the upgrade story for our target Laravel version before committing.

Suggested success measures:

• Developer-days per new admin form, before vs. after.
• Count of form changes shipped by non-engineers.
• Lead time on field/validation change requests.
• Number of bespoke form implementations retired.

Recommendation posture: adopt conditionally — approve for Enso-based internal admin surfaces after a short spike; do not adopt as the standard for customer-facing or long-horizon critical flows without a documented exit plan.