Laravel Livewire Steps Laravel Package

Product Decisions This Supports

• Build vs. buy for multi-step flows. The core decision this package informs is whether a wizard is worth building in-house. It is roughly two base classes on top of Livewire 3 form objects, so the honest comparison is "~1–2 days of engineering to hand-roll" versus "one Composer require." Verdict: buy when the flow is linear and server-validated; build when the flow is branching, resumable, or regulated.

• Scoping onboarding, intake, and signup flows. The credible first use cases are 2–3 step linear flows: onboarding intake, newsletter/lead capture, contact-with-confirmation, KYC-lite questionnaires. These are exactly the flows that otherwise sit in the backlog because "it's just a form" — this package makes them a small, scheduled ticket instead of a vague one.

• Deliberately not checkout or payments. The package provides step sequencing and per-step validation and nothing else. Payment idempotency, stock, retries, and audit logging remain product-owned work. This is a scoping decision, not a technical one: keep high-stakes flows off this until the team has run two low-stakes wizards through it.

• Roadmap sequencing for "resumable" and "progress UI." Two capabilities product will inevitably ask for are explicitly out of scope of the package: persistence across refresh (defaults restart at step one) and any progress bar, back button, or step labels. Treating them as known roadmap line items — not surprises — is the right framing when sizing a wizard epic.

• Reusability as an architectural commitment. Steps are reusable form objects, so the same "EmailStep" can be embedded in more than one wizard. That supports a product decision to standardise on shared step definitions (e.g. one canonical address block) rather than letting each flow invent its own, which reduces drift in validation rules across surfaces.

• Conditional/skip logic is available but unowned. Skip-step landed in v1.1.0 and is undocumented. A PM can decide to not commit to conditional flows in a release until engineering has read the source and confirmed semantics — cheaper to defer a feature than to ship a wrong branch.

• Vendor and platform-support risk is low but should be tracked. Recent releases are compatibility bumps (Livewire 4, Laravel 13), which is a healthy signal for a package this small: it is being kept alive against the framework. The counter-signal is 6 stars and zero dependents — effectively one maintainer. Because the surface area is two classes and the licence is MIT, the mitigation is cheap (fork or vendor), so this should not block adoption, but it should be a line in the risk register rather than an unstated assumption.

When to Consider This Package

Consider it when all of the following hold:

• The flow is linear and short (2–4 steps) with no branching beyond an early skip.
• Validation is server-side and per-step, and can live as attributes on a step's own fields.
• The team is already on Livewire 3+, so there is no new runtime dependency or mental model.
• You want a single request per step transition — the explicit reason the author wrote it instead of using spatie/laravel-livewire-wizard, which costs two component requests per step. If step latency or request count is a live concern, this is the differentiator.
• Losing the package would be recoverable in a sprint — acceptable because the code is two base classes you can copy into app/.

Look elsewhere, or budget for real engineering, when:

• The flow is long or high-stakes and must survive a refresh or an abandoned session. Persistence is application work here, not a package feature.
• You need branching, dynamic step graphs, or per-user step sets. Order is declaration order on the class; positional indices mean inserting a step silently redefines "step 2."
• You need progress UI, step labels, or navigation chrome out of the box — none ship, and all must be derived from the step property block.
• You need a supported vendor with an SLA or a security-response commitment. This is a single-maintainer MIT package, not a commercial dependency.
• The flow involves money, inventory, or regulated data. Nothing here helps with idempotency, audit trails, or retry semantics.
• You want a battle-tested ecosystem with community answers when something breaks. With 0 dependents, you will be the first to hit most edge cases.

How to Pitch It (Stakeholders)

For executives (one line): It turns our recurring "multi-step form" backlog items into small tickets without adding a dependency we can't walk away from — it's ~two classes of code under a permissive licence, so the downside is bounded and the time saved is per-flow.

For engineering leadership:

• Cost of adoption: a Composer require, no config, no migrations, no service provider. The real onboarding cost is reading two source files, because the README omits navigation semantics, previous-step behaviour, and the undocumented skip feature added in v1.1.0.
• Cost of ownership: deliberately capped. Standardise on one thin BaseWizard in app/ that every wizard extends, route all step markup through Blade views rather than the README's inline strings, and qualify every wire:model and @error with the step property name. That single wrapper is our exit ramp — if the package stalls or a Livewire upgrade breaks it, we swap one file, not every wizard.
• Known correctness work to schedule, not discover: revalidate all steps before the completion handler runs (earlier steps are not automatically re-checked after a user goes back and edits), and decide at design time whether to persist step state — the default restarts the wizard on refresh.
• What we are explicitly not buying: progress UI, back-button styling, step labels, session persistence, and conditional-flow ergonomics. Budget these as our work in the same epic or cut them from scope up front.
• Risk position: 6 stars, 0 dependents, single maintainer, but recent releases are straightforward Livewire 4 / Laravel 13 compatibility bumps. Low adoption risk is offset by tiny surface area plus MIT, and the BaseWizard seam makes replacement a contained task. Recommend adoption for low-stakes linear flows only, with the first two wizards treated as a deliberate trial before any high-stakes flow is committed to it.