Inertia Forms Laravel Package

Product Decisions This Supports

Feature delivery: form-heavy surface area. Most of the product's "boring but expensive" work lives in forms — profile/settings, onboarding, checkout, application intake, admin CRUD, notification preferences. This package collapses the usual two-artifact pattern (PHP validation + hand-built frontend form) into one PHP class that both validates and renders. For a PM, that means form work becomes a single backlog item with one owner instead of a frontend/backend pair with a handoff and a spec.

Roadmap: multi-step and conditional flows. The wizard mode, per-field visibleWhen() / clearWhenHidden(), and fieldset/column layout primitives make it cheap to ship the flows that usually get deferred for cost: guided onboarding, eligibility/qualification questionnaires, tiered checkout, KYC-style intake. These are roadmap items that often slip because "it's just a form" turns into a bespoke state machine on the client. Here the branching logic is declarative and server-owned.

Roadmap: dynamic, ops-configurable forms. Repeater, Blocks, KeyValue, TagsInput, and server-searchable Combobox are the building blocks for content and data that changes shape — page/section builders, pricing tiers, FAQ lists, line items, address books. This is the difference between "every new content shape needs an engineering ticket" and "an operator can assemble it." It supports decisions like should we build an in-house form builder? — often the answer becomes "no, extend this."

Build vs. buy: replacing a bespoke form abstraction. Many teams eventually write their own field-definition + validation + rendering layer. That layer is typically weeks of engineering plus ongoing maintenance, and it is never the thing customers pay for. This package is a credible buy for that layer, subject to the adoption risk below. Decision framing: buy the plumbing, keep the product-specific validation rules — the rules() escape hatch and #[Validate] controller binding mean the package is the scaffolding, not the business logic.

Standardization decision. Adopting it sets a house style for forms: consistent labels, help text, error placement, submit/intent handling, iconography (200+ names), accessibility defaults. That is a UX consistency win that is very hard to get from a bespoke layer built form-by-form, and it reduces design-review cycles.

Agent-assisted delivery. The bundled skill file and llms.txt index mean coding agents can be pointed at a worked workflow (make:form → fields() → Inertia::render → <Form :form="form" />). For teams already using agents, this measurably lowers the cost per form and improves the odds the generated code matches house conventions instead of inventing a new one.

Explicitly not supported: pricing/packaging decisions, growth instrumentation, or anything requiring form analytics, A/B testing on field order, or conversion attribution. There is no evidence in the docs of built-in submission analytics — assume you instrument that yourself.

When to Consider This Package

Adopt when most of these are true:

• You are already on Laravel + Inertia with Vue, React, or Svelte. The package assumes Inertia's props/render model; it is not a fit for plain Blade, Livewire, or an API-only SPA with a separate frontend team and contract.
• The forms in question are internal, authenticated, or B2B-facing — admin panels, settings, onboarding, intake, dashboards — where a polished-but-standard form is acceptable and pixel-perfect bespoke UI is not required.
• You have many forms, or forms that change often. The value is a function of repetition. Three forms total does not justify a dependency; thirty does.
• You want conditional and multi-step logic without client-side state management. If your roadmap has wizards and branching questionnaires, this is the strongest reason to look.
• You can accept and manage a young dependency: 24 stars, zero dependents, one apparent maintainer. That is fine for a startup shipping fast; it is a procurement problem for a regulated enterprise.
• A named engineer is willing to own it — pin the version, read the changelog, and hold the fork option.

Look elsewhere when:

• Not on Inertia, or your frontend is a separate team with its own design system. The cross-language contract (erag/inertia-forms-vue / -react / -svelte) becomes a coordination cost you do not control.
• Accessibility or security certification is a gate. A 24-star, single-maintainer package will not survive a vendor risk review, and you should not fight that battle for form plumbing.
• You need vendor support, SLAs, or a security response process. MIT gives you the code, not a phone number.
• Highly bespoke UI is the product. If the form is the experience (a signature flow, a design-led checkout, a rich editor), you will spend more time fighting the component than building it. Custom fields are supported via component() + <Form :components="..." />, but that is an escape hatch, not a design system.
• Heavy client-side reactivity — live pricing calculators, complex dependent-field math, offline support. Server-owned field definitions do not help there.
• You cannot fork. If your organization will not vendor an unmaintained package in a year, do not take the dependency now.

Risk posture to state plainly: low maturity signals (stars, dependents, single maintainer) mean this is a pilot-grade dependency, not a platform-grade one. The correct move is a bounded pilot with a sealed wrapper, not a mandate.

How to Pitch It (Stakeholders)

To executives — the one-liner: "We can stop hand-building forms. One PHP class per form defines the fields, the validation, and the layout; the frontend renders it with a single component. Forms are the most repetitive, least differentiating work in the product, and this removes most of it."

The business case in three points:

1. Speed. Form work today costs a backend task (validation, request handling) plus a frontend task (markup, error states, conditional display) plus a handoff and a QA pass to catch where the two disagree. This collapses that into one task with one source of truth for validation — which also eliminates a whole class of "frontend allows it, backend rejects it" bugs.
2. Roadmap unlock. Multi-step wizards, conditional questionnaires, and repeatable/block-based content become small instead of medium. Those are features we have been deferring on cost grounds, not on value grounds.
3. Low financial risk. MIT licensed, no per-seat or per-submission cost, and it is a thin layer over conventions we already use (Laravel validation, Inertia props). Nothing here is a lock-in we cannot walk away from.

To engineering — the honest framing: it is early-stage. 24 stars, no dependents, effectively one maintainer. The API is clean and the field set is genuinely broad (22+ types, repeaters, blocks, file upload, OTP, chat-style composer), but we should treat it as code we are adopting, not a service we are buying. Proposal: a one-sprint pilot on two or three non-critical forms, behind a thin internal wrapper so a future swap is a bounded change rather than a rewrite. If the pilot holds, expand to settings and admin; keep it off the highest-stakes checkout path until it has a track record with us.

The ask: one sprint, one engineer, two forms, and a decision at the end — expand, hold, or fork. Not a platform commitment today.

What success looks like: forms shipped in a day instead of a sprint; no validation drift between client and server; a second engineer able to add a form without reading the frontend code; and a documented exit path if the package stalls.