Nova Wizard Laravel Package

Product Decisions This Supports

• Admin & internal-tool UX investment. Nova is typically where ops, support, and back-office staff spend their day. A wizard pattern directly addresses the highest-friction flows: creating multi-entity records (customer + subscription + billing profile), configuring integrations, and stepping through compliance or onboarding checklists where a single 40-field form causes errors and abandonment.
• Roadmap sequencing for internal tooling. If your roadmap has "reduce ops handling time" or "cut data-entry errors in the admin panel" as a Q-level objective, this package is a candidate lever with a near-zero build cost — useful for deciding whether to spend the next sprint on wizard UX or on a different internal-tool gap.
• Build vs. buy vs. adopt decision. A wizard is deceptively expensive to build well: step state, validation scoping per step, back/forward navigation, persistence across reloads, and Nova's Vue component conventions all need handling. This package competes against (a) a custom Nova tool built in-house, (b) a bespoke Inertia/Livewire admin page outside Nova, or (c) restructuring the form to be simpler instead. The PM decision is which of these is cheapest to own over 12 months, not cheapest to ship.
• Scoping complex resource creation. Multi-step flows force a product conversation about field grouping, required-vs-optional sequencing, and where validation gates belong — valuable even if you ultimately don't adopt the package.
• Onboarding and guided-setup features. Where "wizard" appears in customer-facing or tenant-setup requirements, this is a reference implementation for the interaction model inside the Nova surface, though it is not a customer-facing wizard.
• Vendor-risk budgeting. With 14 stars and zero dependents, adopting this is a build-with-a-head-start decision, not an integrate-a-platform decision. That framing should be explicit in any roadmap entry that relies on it.

When to Consider This Package

Consider it when all of the following hold:

• You are on Laravel Nova 4 specifically, with no near-term plan to move to Nova 5 (or you accept a migration task when that happens).
• The target flow is internal-facing — staff, ops, or a small set of trusted admin users — where a broken step is an annoyance, not a customer-visible incident.
• You have Laravel/PHP engineering capacity to read, patch, and if necessary fork a small package. At 14 stars and 0 dependents, the practical maintenance model is "we own this code after adopting it."
• The wizard need is genuinely multi-step (3+ logical stages with distinct validation per stage), not a long form that would be better served by Nova fieldsets, dependent fields, or simply splitting the resource into related models.
• You need it now and a two-to-four week custom Nova tool build is not justifiable for the value delivered.
• License ambiguity is resolvable. NOASSERTION means the repository's license could not be automatically classified — treat this as unknown, not permissive. Get legal/OSS review before it lands in a proprietary product, and confirm the actual LICENSE file contents; this is a hard blocker for anything shipped to customers or distributed.

Look elsewhere — or build in-house — when:

• You are on Nova 3, or on a Nova version the package has not been updated for. Nova major upgrades break custom tools routinely; a 14-star package will not be maintained ahead of them.
• The flow is customer-facing or revenue-critical, or touches regulated data where an unmaintained dependency in the request path is unacceptable.
• You need guarantees: SLA, security disclosure process, CVE response, or an actively maintained upstream. None of those exist here.
• You require audit-grade wizard behavior — resumable drafts, versioned step definitions, per-step audit trails. Expect to extend significantly.
• You only think you need a wizard. A single well-organized form with fieldsets and Nova's built-in validation is cheaper to maintain and less likely to frustrate power users. Exhaust that option first.
• Your organization has a policy against dependencies with unknown licenses or below a maintenance threshold — in which case the correct output is a build estimate, not an adoption decision.

How to Pitch It (Stakeholders)

For executives (one paragraph): We are evaluating a small open-source add-on for our Laravel Nova admin panel that lets us turn long, error-prone back-office forms into guided multi-step wizards. The direct cost is essentially zero and it could compress a multi-week internal-tool build into days, which matters if reducing ops handling time or data-entry errors is on this quarter's list. The caveat is that it is a very small, low-adoption project with an unresolved license, so the honest framing is "a head start on code we will own and maintain ourselves," not "a vendor we can lean on." Recommend a time-boxed evaluation on one internal flow, with legal review of the license before anything ships.

For engineering leads (the substance): Nova 4 only; a thin wrapper over Nova's form/tool conventions for step-wise resource creation. Zero dependents and 14 stars means no upstream safety net and no community testing surface — plan to pin the version, vendor or fork it, and treat it as internal code from day one. Before committing, verify: does it handle per-step validation cleanly, does it preserve state on back/forward and on reload, and how does it behave when a step's validation fails server-side? If the answer to any of those is poor, the fork cost likely exceeds a clean in-house Nova tool.

Ask: Approve a one-flow, one-sprint spike (internal-only, non-regulated data) plus a legal review of the license. Success criteria: shipped on one real admin flow, no manual state-loss bugs in two weeks of ops use, and a documented fork-and-own plan. If the spike fails those, we fall back to fieldsets or a scoped in-house tool with a real estimate in hand.