Starter Kits Laravel Package

Technical Evaluation

Architecture fit

shopper/starter-kits is not a runtime dependency. Since v1.1.0 it is a community-driven registry plus a manifest convention (shopper-kit.yaml) that the Shopper CLI (php artisan shopper:kit:install <package>) consumes to copy files, install dependencies, and run post-install commands. Nothing from this repo ships into production.

For a TPM, that shapes the entire evaluation:

• Risk is not in the registry — it is in the kit you install. The registry contributes almost no runtime or supply-chain surface. The Livewire, Vue, or React kit you select becomes part of your application source and inherits none of the registry's abstraction. Assess the specific kit repo separately; do not let "17 stars" stand in as a proxy for the storefront's risk profile.
• The decisive property is "scaffold, not theme." Installation is a one-time copy; the code is yours to modify or delete. This suits teams that need durable ownership and refuse vendor lock-in. It is the wrong instrument for teams expecting upstream-pushed theme updates, because there is no update channel — only a re-fork.
• Frontend architecture is the real product decision. The registry now offers three parallel paths: Livewire + Alpine, Inertia + Vue 3, and Inertia + React 19 (all Tailwind v4, Wayfinder routes, multi-currency zones, cart, checkout, Stripe). Choosing between them is a hiring, ramp-up, and long-term maintainability decision that outlives the package.
• The manifest is a privileged contract, not documentation. Declared files, dependencies, and post-install commands execute with your application's privileges during setup. Treat kit installation as a controlled build step.
• Coupling to Shopper is total. This package inherits Shopper's maturity, its Laravel version policy, and its bus factor. It cannot be evaluated as a standalone library.

Integration feasibility

• Low effort when Shopper is already the platform: CLI install, migrate, build assets, smoke-test core flows. Scopable in days, not weeks.
• High effort when Shopper is not adopted: the actual decision is "adopt Shopper," and the kit is the last mile. Size the Shopper evaluation — feature parity against the incumbent, checkout and payment integration, multi-currency/tax/shipping behavior — as the real workstream, with the kit as a spike within it.
• Non-conflicting by construction. Files land in the application tree, not vendor/, so there is no collision with existing packages. The same property removes any upstream patch channel.
• Install-once semantics. There is no upgrade path from kit v1 to kit v1 next quarter; the versioned releases on the registry describe the scaffold's history, not something you can pull. Each install is effectively a fork point.

Technical risk

Key questions

1. Is this a platform decision or a scaffolding decision? If Shopper is not already the platform, this package must not be the justification for adopting it.
2. Which frontend path do we commit to? Livewire/Alpine, Vue, or React — this determines hiring and enablement, and the kits are not interchangeable after installation.
3. Who owns the fork? Name the engineer accountable for tracking upstream release notes across the kit, Shopper, and Livewire, and for re-applying changes.
4. What is the exit path? Can we rebuild or re-platform the frontend without discarding domain logic? If not, the scaffold is a lock-in of our own making.
5. What does "done" look like for the pilot? Define acceptance as product browse → cart → checkout → account, plus two non-happy paths (zone unavailability, abandoned or failed payment) and a currency-rounding assertion.
6. Do we contribute back? If we intend to run multiple Shopper projects, is the registry a convention we adopt, fork, or maintain internally?

Integration Approach

Stack fit

The registry presupposes Laravel + Shopper. Within that, fit depends on the chosen kit:

• Livewire + Alpine kit — best when the team is Laravel-native and wants the smallest number of runtimes (no separate JS SPA build, no Node SPA framework). Lowest cognitive overhead for a backend-weighted team.
• Inertia + Vue 3 or React 19 kits — best when the team already has Vue/React depth or when the storefront must share components and idioms with other frontend surfaces. Trades a Laravel-only mental model for a two-runtime one.
• Common to all kits — Tailwind v4, Wayfinder routes, multi-currency zones, cart, checkout, accounts, Stripe. These represent opinionated defaults that will be partially rewritten; scope them as starting points, not delivered features.
• Poor fit when the organization needs enterprise support, SLAs, a visual theme marketplace, or non-Laravel backends.

Migration path

• Greenfield (preferred): new Laravel application → install Shopper → install the chosen kit via the CLI → configure zones, currency, and Stripe → build assets → smoke-test. Fastest and lowest-risk route.
• Brownfield: the kit is not designed to be grafted onto an existing storefront. Realistically it becomes a reference implementation: stand up a parallel application, port domain configuration, then cut over. Budget for that rather than assuming in-place adoption.
• Data migration is out of scope. The kits scaffold presentation and flows; catalog, customer, and order migration from any incumbent system is a separate workstream and the largest hidden cost in a brownfield move.
• Note the v1.1.0 structural break. Anything written against v1.0.x describes a Breeze-style monolithic scaffold; v1.1.0 replaced it with the registry-plus-manifest model. Ignore older tutorials and internal notes.

Compatibility

• Registry is version-agnostic; each kit is not. Pin Laravel, Livewire (or Inertia/Vue/React), Tailwind v4, PHP, and Node versions in the generated project and record them in the decision log.
• Stripe integration is bundled but bare — confirm webhook handling, idempotency, refunds, and failed-payment states against your own requirements rather than assuming kit coverage.
• Multi-currency zones are a shipped feature; verify rounding and display behavior with real price fixtures before sign-off, given the earlier pricing-helper defect.
• No compatibility guarantee runs forward from the kit to future Laravel/Livewire majors. Assume you will absorb those upgrades manually.

Sequencing

1. Decide — confirm Shopper is the platform independently of the kit; select the frontend path against team skills, not fashion.
2. Spike (time-boxed) — install the chosen kit in a throwaway application; record install friction, manifest contents, and time to a working checkout.
3. Acceptance — execute the browse → cart → checkout → account flow plus non-happy paths; add automated coverage for money math and zone state.
4. Customize — rebrand, restructure, and remove unneeded scaffold; tag the point where the codebase diverges from upstream.
5. Harden — CI smoke tests, dependency pinning, Stripe edge cases, observability wiring.
6. Decide on scale-out — only after one successful pilot, formalize the kit as an internal convention for subsequent projects.

Operational Impact

Maintenance

The maintenance story is the single most important thing to communicate upward: after installation, there is no upstream. "You own the code" is a benefit for velocity and a cost for lifecycle. Concretely, budget:

• A named owner for tracking release notes across the kit, Shopper, and the chosen frontend framework.
• A recurring line item for framework-major upgrades, which will be manual re-application rather than a composer update.
• A divergence log or tagged baseline so future upstream kit releases can be diffed, not blindly re-applied.
• CI smoke tests on core commerce flows, since silent drift after a Laravel or Livewire bump is the most likely failure to go unnoticed.

Support

• Support is community-only, MIT-licensed, with a single primary maintainer and no commercial backing. There is no SLA, no escalation path, and no vendor to call.
• Documentation lives in the Shopper docs site; the registry itself contributes a README, a contributing guide, and release notes — enough to install, not enough to troubleshoot.
• The realistic support model is internal: one accountable engineer, a documented runbook for install and upgrade, and a standing assumption that questions go unresolved until you resolve them. Do not commit to external stakeholders on the basis of upstream responsiveness.

Scaling

• The kit is a presentation and flows scaffold. It offers no scale guarantees, no load benchmarks, and no performance characteristics. Scaling is a Shopper/Laravel/infrastructure concern: queue workers, session and cache stores, search, payment idempotency, and multi-currency correctness under concurrency.
• The registry's scaling value is organizational, not technical: once one kit is validated, it becomes a repeatable project shape across multiple Shopper builds, enforceable in CI via manifest schema checks and layout linting. That is where the compounding return sits.
• Commercial scale-up will require investment beyond the scaffold in the same proportion as any Laravel storefront — treat the kit as saving weeks, not quarters.

Failure modes

Ramp-up

• Budget 3–5 dev-days of enablement for whichever frontend path is chosen, before any delivery commitment. The kit accelerates setup; it does not accelerate unfamiliarity.
• Add 1–2 days for one engineer to walk the manifest and CLI install end to end and document the process, so installs are reproducible rather than tribal knowledge.
• Design and product stakeholders need an explicit framing session: this is a scaffold you will reshape, not a theme you configure. Expectation-setting here prevents the "where is the admin panel for changing the homepage" conversation later.
• Treat the first project as a pilot with published success criteria — time to working checkout, customization effort, upgrade burden — and decide on broader standardization only after those numbers are in hand.