Wizard Bundle Laravel Package

Product Decisions This Supports

• Multi-step flow architecture (onboarding, checkout, KYC, configurators): the bundle's core value proposition is orchestrating ordered steps, transitions, and back/forward navigation — a recurring pattern in any funnel where users complete a sequence of forms before a terminal action.
• Build vs. buy vs. borrow for step orchestration: forces an explicit decision on whether wizard state machines are a differentiator (build in-house, own the UX edge cases) or commodity plumbing (borrow a pattern or a maintained library).
• Scope of a "wizard" feature in the roadmap: clarifies whether the product needs linear navigation only, or conditional branching, save-and-resume, validation gates, and per-step persistence — the latter usually pushes you toward Symfony Workflow or a bespoke state machine.
• Reuse across teams: a shared step/transition abstraction can standardize how multiple funnels (signup, billing setup, account verification) are implemented, reducing per-feature design debates.
• Vendor and maintenance risk budgeting: with 1 star, 0 dependents, and archived status, adopting it is a decision to own a fork, which belongs in the risk register, not just the dependency list.
• Stack fit: note this is a Symfony bundle, not a Laravel package — if the codebase is Laravel, the decision is "reimplement the pattern," not "composer require."

When to Consider This Package

Consider only in narrow cases:

• You are on Symfony (not Laravel) and already have this bundle in the dependency tree — then the question is remediation, not adoption.
• You need a reference design for wizard step/transition modeling and want to read ~a few hundred lines rather than design from scratch.
• You are building internal, low-risk tooling (admin back-office flows, prototype funnels) where abandonment cost is near zero.
• You have engineering capacity to fork and own the code: MIT license permits it, and the surface area appears small enough to vendor.

Look elsewhere when:

• Greenfield or customer-facing revenue paths (payments, identity, PII): an archived repo with no maintainer, no security response, and no dependents is an unacceptable supply-chain position.
• You are Laravel-first: idioms won't map (service container, bundle config, event system); port cost exceeds writing the flow yourself.
• You need active support, PHP/ Symfony version currency, or CVE patching.
• You need conditional branching, retry semantics, or persistence guarantees — evaluate Symfony Workflow (maintained, first-party) or a thin in-house state machine instead.
• You need evidence of quality: no meaningful test/CI signal is visible at this adoption level; treat it as unvetted code.

How to Pitch It (Stakeholders)

Executive summary: ruwork/wizard-bundle is a small, MIT-licensed Symfony bundle for multi-step wizard flows. It is archived, has 1 GitHub star and zero dependents, and therefore should not be treated as a supported dependency. My recommendation is do not adopt for production; use it at most as a design reference or a vendored fork with a named internal owner.

The product need is real; the package is not the answer. Multi-step flows (signup, checkout, verification) are on our roadmap regardless. The build-vs-buy question is genuinely open, but the realistic options are (a) Symfony Workflow / equivalent maintained library, or (b) a small in-house step orchestrator — likely days, not weeks of engineering for a linear flow.

Cost framing: license cost is zero; total cost of ownership is not. An archived dependency means we absorb bug fixes, PHP upgrades, and security patching. For a 1-star repo with no community, that is a permanent, undocumented tax on one team.

Risks if adopted: abandonment (already realized), no security response path, no upgrade path across Symfony majors, and silent breakage with no dependents to surface issues. For anything touching money or personal data, this is a compliance and audit finding waiting to happen.

Ask: approve a short engineering spike (1–2 days) to specify our wizard requirements and compare in-house vs. Symfony Workflow. Treat this bundle as input to that spike only — no production dependency, no roadmap commitment tied to it.