Progress Stepper Laravel Package

Product Decisions This Supports

• Build vs. buy for multi-step UI: A stepper/progress indicator is a recurring pattern in onboarding, checkout, KYC, application wizards, and setup flows. Adopting a maintained package avoids re-implementing the same navigation, step-state, and progress-rendering logic in every funnel — a decision worth making once, at the platform level, rather than per feature team.
• Roadmap sequencing for onboarding and conversion work: If onboarding completion or checkout drop-off is on the roadmap, having a stepper primitive available shortens the path from spec to shippable. It makes "add a step" a content change rather than a UI engineering project, which affects how aggressively you can iterate on funnel experiments.
• Scope negotiation with design: Standardizing on a shared stepper constrains the design conversation to step count, labeling, and progress semantics — reducing bespoke design work and review cycles per flow.
• Risk posture on dependency footprint: Reaching a 1.0.0 tag is a signal the maintainer considers the API stable enough to commit to. That is a meaningful (if not sufficient) input to a dependency-approval decision, especially for a small, single-purpose package that is easy to swap out later.

Caveat for the decision record: the 1.0.0 release notes contain only a changelog link — no feature list, no breaking-change detail, no upgrade path. This assessment is therefore inferred from the package name and Laravel ecosystem conventions, not from documented capability. Treat it as a hypothesis to validate in a timeboxed spike before it enters a roadmap commitment.

When to Consider This Package

Consider it when:

• You have two or more flows that need step-based progress indication, or one flow you expect to iterate on repeatedly — below that threshold, a handful of Blade partials is cheaper than any dependency.
• You want a presentation-layer-only component. A stepper should not own your wizard's business logic, validation, or persistence; if the package tries to, evaluate whether it will fight your existing form and state management.
• Your stack is already Laravel + Blade/Livewire and you value a small, single-purpose dependency over a broad UI kit.
• You can absorb the risk of a young package. At 1.0.0 by an individual maintainer, expect limited community surface area, thin documentation, and a real (if low-cost) bus-factor exposure.

Look elsewhere or build in-house when:

• You need accessibility guarantees (focus management, ARIA step semantics, screen-reader announcements on step change). Multi-step flows are a common a11y failure point; a package without documented a11y behavior is a liability in regulated or public-sector contexts.
• You need deep customization of markup, or you are on a frontend stack (Vue/React/Inertia) where a Blade-oriented component adds a seam rather than removing one.
• Your flow requires persistence, resumability, or deep-linking to steps — that is application logic, not a UI package.
• Your organization requires maintained dependencies with active issue response and security disclosure policy. Verify commit cadence and open-issue handling before adoption; you cannot infer this from a 1.0.0 tag.

Validation checklist before approving: confirm the actual feature surface (Blade component? Livewire? configurable step states?), supported Laravel/PHP version range, test coverage, license, whether it ships CSS/JS assets or assumes your design system, and whether 1.0.0 introduced any breaking change relative to pre-1.0 tags. The changelog link should be read, not assumed.

How to Pitch It (Stakeholders)

To executives (one paragraph): We are evaluating a small open-source Laravel component for multi-step progress indicators — the "Step 1 of 4" pattern used in onboarding, checkout, and application flows. The business case is speed and consistency: it lets teams add or reorder funnel steps without bespoke UI work, which shortens iteration cycles on the flows most directly tied to conversion and activation. Cost is negligible (free, MIT-class dependency), the integration surface is small, and it is easily removed if it disappoints. Its 1.0.0 release marks API stability, which is the milestone we were waiting for before considering it — but the release notes are thin, so we are recommending a short engineering spike before any roadmap dependency on it. Ask: approval to spend a few days validating, not a commitment to adopt.

To engineering (short form): New 1.0.0 of batistackapp/progress-stepper. No prior assessment existed, and the release notes only link the changelog — so nothing here is confirmed except that the maintainer has cut a stable tag. Proposal: a timeboxed spike to answer four questions — (1) what does it actually render and what does it own? (2) what Laravel/PHP versions and frontend assumptions? (3) is it accessible out of the box, or do we own that work? (4) is the 1.0.0 API stable and is the maintainer responsive? If it clears those, it is a low-risk convenience dependency for wizard UI; if not, we write the ~100 lines ourselves and keep the control. Either way, do not let it own wizard state or validation — presentation only.