Starter Kits Laravel Package

Product Decisions This Supports

• MVP vs. full build sequencing. The package supports a "buy the starting point, build the differentiation" decision. It is a registry of scaffold templates — not a theme — installed once with php artisan shopper:kit:install <package>, after which the code is copied into your application and owned outright. That materially lowers the cost of reaching a demoable storefront (product pages, cart, checkout, accounts, Stripe) and lets you defer a large custom-build commitment until the funnel has been validated.
• Frontend architecture choice (now a real choice). As of v1.1.0 the registry lists three official storefront kits: Livewire + Alpine, Inertia + Vue 3, and Inertia + React 19 — all with Tailwind v4, Wayfinder routes, multi-currency zones, cart, checkout, and Stripe. This turns a previously single-path Livewire decision into a genuine stack selection that can be made against existing team skills rather than against vendor constraints.
• Roadmap gating for Shopper itself. If Shopper is already the platform, this is a last-mile productivity decision. If it is not, this package should not be the justification for adopting Shopper — the real workstream is the Shopper evaluation (feature parity, checkout/payment integration, multi-currency and zone behavior, tax/shipping), and the kit only accelerates the final step.
• Standardization across a portfolio of stores. The registry is a convention, not a capability: a shopper-kit.yaml manifest declares which files to copy, which dependencies to install, and which commands to run. For organisations planning more than one Shopper storefront, that becomes an internal standard enforceable in CI (manifest schema checks, file-layout linting) and a way to keep project shapes consistent.
• Build vs. buy on the storefront layer. Choosing a starter kit is choosing code ownership over vendor-managed templates. It fits teams that want to modify, delete, or reorganise freely and refuse theme lock-in; it explicitly does not fit teams that want upstream-pushed theme updates.
• Use cases this fits: new Shopper storefront MVPs, internal proofs of concept, UX/design validation with stakeholders, small B2C storefronts, and evaluation spikes where the acceptance bar is browse → cart → checkout → account plus one non-happy path (e.g. unavailable zone, abandoned cart).
• A decision this does not support: treating the registry's adoption metrics as evidence of the storefront's production readiness. Stars and dependents describe the registry; the risk profile lives in the specific kit you install.

When to Consider This Package

Adopt (as a pilot) when:

• Laravel is already the stack and Shopper is already approved or actively being evaluated as the commerce foundation.
• You need a customisable starting point, not a finished theme, and the team is genuinely willing to own scaffolded code after install.
• One of the three official frontend paths (Livewire, Vue 3, React 19) matches your team's existing skills — otherwise you are buying a ramp-up cost, not a speed-up.
• You want an open-source, MIT-licensed path with no procurement cycle and full code ownership.
• The timeline rewards time-to-demo over long-term vendor guarantees, and the storefront is not business-critical from day one.

Look elsewhere when:

• You need SLA-backed support, compliance artefacts, or a large partner ecosystem — this is a small, community-driven package (17 stars, 0 listed dependents, effectively single-maintainer release cadence).
• Your stack is not Laravel/Shopper, or you are unwilling to take on Shopper's own maturity and roadmap risk.
• You need a visual theme marketplace with non-developer customisation rather than a code scaffold.
• Your frontend strategy is headless or sits outside the three offered kits, and you do not want to own a fourth path yourself.
• You require an upstream patch channel. "The code is yours" also means Shopper/Livewire security and breaking-change remediation is silently your work — if nobody will fund a recurring upgrade line item, do not adopt.

Additional guardrails for the PM:

• Assess the kit, not the registry. Installation executes manifest-declared file copies, dependency installs, and post-install commands with your application's privileges. Treat it as a privileged build step, reviewed and run in a controlled/CI context.
• Note the churn signal. v1.1.0 replaced the Breeze-style scaffold with the community-driven registry model, and v1.0.x was a rapid sequence of design and layout iterations. That is healthy movement for an early package, but it means interfaces and conventions are still settling — pin versions and expect rework.
• Name an owner before you commit. Decide who owns the fork, tracks upstream release notes for the kit/Shopper/Livewire, and re-applies changes.
• Define the exit path up front. If you cannot rebuild the storefront on another frontend without discarding domain logic, the scaffold has become lock-in of your own making.
• Gate expansion on evidence. Success criteria should be measurable: time to first demo, install friction, customisation effort, upgrade cost, and test coverage. Expand usage only after a non-critical project clears those bars.

How to Pitch It (Stakeholders)

For executives. Shopper Starter Kits are a free, MIT-licensed way to shorten the path from "we think we need a storefront" to "here is a working storefront you can click through." They give teams product pages, cart, checkout, accounts, and Stripe payment as a starting point — and because it is a one-time scaffold rather than a licensed theme or platform, the code becomes ours and there is no recurring vendor fee or lock-in. We now have three official frontend options, so the choice can follow the skills we already have on staff. The honest caveat is maturity: this is a small, community-driven package with a narrow contributor base and no formal support. My recommendation is to approve it as a contained, time-boxed pilot with explicit success criteria — time to demo, customisation effort, and ongoing maintenance burden — rather than adopting it as a platform standard. The upside is speed and optionality; the downside of getting it wrong is a modest amount of engineering time, not a multi-year commitment.

For engineering. This is a registry plus a manifest convention, not a runtime dependency — it introduces no production coupling. Kits install via php artisan shopper:kit:install <package>; each ships a shopper-kit.yaml declaring files to copy, dependencies to pull, and post-install commands to run, and the output lands in the application rather than vendor/. Three official kits are available: Livewire + Alpine, Inertia + Vue 3, and Inertia + React 19, all on Tailwind v4 with Wayfinder routes and multi-currency zones. Two things to plan for. First, install executes commands with application privileges — review the manifest and run it in a controlled context. Second, because we own the copied code, there is no upstream patch channel: Shopper and Livewire upgrades become our remediation work. So the ask is a spike that pins versions, adds a CI smoke test over browse → cart → checkout → account, documents our customisations to keep the scaffold diffable against upstream, and confirms the exit path before we put this on a delivery roadmap.