Laravel Livewire Wizard Laravel Package

Product Decisions This Supports

Feature feasibility and delivery of multi-step flows. The package is purpose-built for one job: a sequence of screens where each step is its own Livewire component and steps can read each other's state. That directly maps to a large share of high-value product surfaces — checkout, signup/onboarding, KYC and identity verification, loan or insurance applications, quote builders, appointment booking, SaaS setup wizards, compliance questionnaires, and long surveys. If a roadmap item is "turn this 40-field form into something users actually finish," this is a credible delivery mechanism rather than a research spike.

Build vs. buy for flow scaffolding. Without a package, a team hand-rolls a step registry, current-step state, navigation events, and cross-step state aggregation — typically a week or two of engineering plus ongoing maintenance, and it is exactly the kind of glue code that rots quietly. Adopting this reduces that to a dependency plus per-step views. The decision to buy here is cheap to reverse: MIT license, no procurement, thin surface area over Livewire, and no proprietary data model. Frame it as "we are not buying a wizard product, we are not writing boilerplate."

Design and scope control. The package is explicitly headless — it ships no UI, no CSS, no navigation chrome. That is a product decision in itself: it means your design system owns the experience (progress indicators, back/next affordances, mobile layouts, error states), and it also means UI work must be scoped into the estimate. Teams that adopt headless packages expecting a drop-in screen routinely under-budget the front-end by more than the package saves.

Conversion and progressive-disclosure experiments. Because the step list is a simple array on a component class, reordering, adding, or splitting a step is a small change rather than a refactor. That makes it practical to run experiments on flow length (fewer, denser steps vs. more, lighter steps), step ordering, and where to place friction — a real roadmap lever for checkout and onboarding funnels, not just an implementation detail.

Quality and regression budget. The package has first-class testing support (testStep, testable wizards, added across 1.1.0 and 2.4.0). Multi-step flows are notoriously under-tested because each step is a partial state machine; having the harness baked in lowers the QA cost of long flows and makes "we'll test it later" less defensible.

Platform standardization. If multiple teams are each building step flows, standardizing on one headless primitive gives consistent navigation semantics and a shared mental model. Note the 2.0.1 fix for multiple wizards on a single page — relevant if you plan to embed flows inside dashboards.

Decisions this package does not make for you (scope these explicitly, they are the hidden roadmap items):

• Draft persistence / resume later. Cross-step state lives in the Livewire component lifecycle; durable, server-side "come back tomorrow" resumption is your build, not theirs.
• Analytics and abandonment instrumentation. No funnel telemetry out of the box; you must emit step-view and step-abandon events yourself or you will ship a flow you cannot measure.
• Conditional branching and step skipping. Skip-step functionality was removed in 1.0.1. If your flow is genuinely dynamic (branch on user type, product, or jurisdiction), budget for building that logic on top, or evaluate alternatives.
• Cross-step validation orchestration. Per-step validation is natural; "cannot proceed until step 2 and 3 are mutually consistent" is application logic.

When to Consider This Package

Adopt when:

• You are already on Laravel + Livewire 3 (changelogs show active compatibility through Laravel 12). If Livewire is not in the stack, this package is irrelevant — do not adopt Livewire to adopt a wizard.
• The flow is multi-screen with shared state and a review/summary step that needs to read prior answers — this is the package's sweet spot and where the cross-step state access earns its keep.
• Design owns the UX and you have an in-house component library; a headless primitive is an asset, not a gap.
• You want a small, forkable, MIT-licensed dependency from a vendor with a long track record (Spatie) rather than a framework-sized commitment.
• The flow lives inside your product, not inside an admin panel.

Look elsewhere when:

• You are on Filament. Use Filament's built-in wizard — adopting this instead means duplicating form/state handling you already have.
• You need prebuilt navigation and CSS. vildanbina/livewire-wizard ships UI; this one deliberately does not.
• Your flow is simple (two or three screens, no cross-step reads). A single Livewire component with form objects, or satoved/laravel-livewire-steps, is less machinery for the same outcome.
• You need durable drafts, resumable links, or funnel analytics as requirements, not nice-to-haves. Those are build items here and may be first-class elsewhere.
• Your flow is heavily branching. Removed skip-step support means you are writing that layer yourself; compare against a more opinionated tool before committing.
• The front end is Inertia/React/Vue. Wrong layer entirely.
• Your team has no Livewire experience. The package is thin, but the learning curve is Livewire's, not the package's — factor onboarding into the estimate.

Diligence note before committing. 418 stars with no listed public dependents is modest social proof — the reputation of the maintainer carries more weight than the ecosystem signal here. Mitigate with a one-to-two day spike: build two real steps of your actual flow, including the summary step and one conditional branch, and confirm the state-access ergonomics and testing helpers match how your team works. Expected integration effort for a typical flow is on the order of days per flow for engineering, plus the design and instrumentation work above.

How to Pitch It (Stakeholders)

For executives — the one-paragraph version: We can ship multi-step flows — checkout, onboarding, applications — significantly faster by using a small, free, open-source library from Spatie, a well-established Laravel vendor, instead of writing our own step-flow plumbing. It is MIT licensed, so there is no cost and no procurement, and because it is a thin layer over technology we already use, the lock-in risk is close to zero: if we ever outgrow it, replacing it is a contained piece of work, not a re-platforming. The trade-off is honest — the library provides the mechanics, not the screens or the analytics, so design and instrumentation remain in our scope. Net: it converts a recurring "build a wizard from scratch" cost into a small, reversible dependency.

For engineering — the substance: It is headless by design. A wizard is a WizardComponent with a steps() array of ordinary StepComponent classes, each a normal Livewire component — so existing patterns, validation, and views all apply, and there is no new mental model to learn. Cross-step state is readable, navigation is yours to render, and there is a built-in testing harness (testStep) so long flows are testable rather than a manual QA burden. It tracks Livewire 3 and current Laravel releases, is actively maintained with a changelog and documented releases, and is small enough to read in an afternoon and fork if needed. Known gaps to plan around: no UI, no persisted drafts, no funnel analytics, and no built-in conditional step skipping (removed upstream) — those are ours to build.

For design — the ask: The library deliberately ships zero visual opinions. That means we own the entire experience — layout, progress affordance, mobile behavior, error and back-navigation states — and it means the flow will look like our product rather than a third-party widget. Design input is required before engineering starts, not after.