Ecommerce Storefront Livewire Laravel Package

Product Decisions This Supports

• Build vs. buy for storefront UI: This is the "buy" (or rather, adopt) half of a headless commerce stack. The engine owns catalog, cart, checkout services, and data; this package owns the shopper-facing frontend. That split lets the team buy the commodity storefront (catalog grids, PDPs, cart drawer, checkout wizard, account pages, SEO, a11y) and spend engineering on the parts that differentiate the business.
• Launch readiness for a direct-to-consumer store: With v1.0.0 stable and MIT-licensed, the package covers the full happy path a first store needs — browse → PDP → cart → guest or registered checkout → payment → confirmation — plus the trust-and-conversion basics (coupons, shipping estimates, stock scarcity, order lookup, order history, downloads/licence keys for digital goods). That's a roadmap milestone, not a backlog item.
• Scope decisions on storefront features: The package makes several product choices explicit and configurable, which the PM can use as defaults to debate against: multi-step vs. single-page checkout (store-owner configurable), guest checkout with optional account creation, verified-email requirement for claiming guest orders, cart-merge-on-login prompt, currency switcher tied to the open cart, marketing consent captured on the order and customer. Each is a product decision the team can accept, override, or defer.
• Extensibility budget: The registry and filter/action surface (payment drivers, purchase forms, catalog filters/sorts, product/cart/checkout sections, header actions, AccountMenuRegistry) means the team can ship custom merchandising, upsell logic, or a bespoke gateway without forking. That's a strong signal for investing in integrations rather than the shell.
• Satellite roadmap sequencing: The package registers with the engine's SatelliteRegistry and exposes visual-editor blocks and SEO/schema hooks when those sibling packages are installed. That tells the PM which adjacent packages unlock which capabilities (visual editing, structured data, media srcset), useful for planning an internal platform rollout.
• Payment strategy: A driver registry plus Stripe Element/3DS and a generic redirect driver, with card data kept out of Livewire state, means adding a second or third gateway is a plugin effort, not a storefront rewrite. Good for markets requiring local payment methods.
• Accessibility and compliance as a feature, not a cost: WCAG 2.2 AA targeting (skip link, live regions, error summaries, focus management, 320px layouts, RTL) is a differentiator for public-sector, EU, and enterprise buyers, and reduces the risk of a late-stage remediation crunch.
• Internationalization decision: English, Spanish, French, German out of the box plus RTL locale support is enough to justify a multi-locale launch conversation rather than treating i18n as a future "phase 2."

When to Consider This Package

Adopt when:

• The product is built on the ArtisanPack UI ecommerce engine 1.1 and the team wants a production-grade Livewire storefront without building one from scratch.
• The stack is Laravel 12/13, Livewire 3.6+/4, PHP 8.3+ with ext-intl — non-negotiable prerequisites; verify before committing.
• The business needs the standard commerce surface (catalog with facets and search, multi-product-type PDPs, cart with coupons and shipping estimates, wizard/single-page checkout, customer accounts, guest lookup, downloads) and expects to differentiate elsewhere.
• Accessibility and SEO are buying criteria rather than nice-to-haves — the built-in WCAG 2.2 AA work, JSON-LD, canonical, and noindex handling on transactional pages represent significant avoided cost.
• Multi-locale or RTL is on the near-term roadmap.
• Payment flexibility matters — Stripe today, additional gateways plausibly soon — and the team wants those additions to be additive, not storefront surgery.
• The team wants upgrade safety: semantic versioning starting at 1.0.0, release gating on contract verification and signed reports, CHANGELOG-matched tags, and a documented install command that validates host routes and warns about missing gateways.

Look elsewhere when:

• The business is not on the ArtisanPack UI engine — this is a satellite, not a standalone storefront; there is no fallback path.
• The team needs a marketplace, B2B pricing, subscription billing, or complex promotion engine out of the box — the extension points would carry that weight, but it's custom work.
• The team cannot meet PHP 8.3+, Laravel 12/13, Livewire 3.6+/4, or lacks ext-intl.
• Headless/API-first commerce with a non-Livewire frontend (React, Vue, native apps) is the requirement — the value here is the Livewire server-rendered experience.
• The team wants a fully managed, vendor-supported storefront with SLAs: this is MIT-licensed community software; support comes from the team's own engineering and the ecosystem.

How to Pitch It (Stakeholders)

To executives (30 seconds): The ArtisanPack UI storefront has reached its first stable release. It is the complete shopper-facing layer for an ArtisanPack commerce build — catalog, product pages, cart, checkout, payments, accounts, guest order lookup, SEO, and WCAG 2.2 AA accessibility — released under MIT on the engine we already depend on. Adopting it removes months of storefront engineering from the critical path and lets us spend that budget on merchandising, integrations, and the parts of the experience customers will actually notice.

To engineering leadership: This is a well-scoped satellite: it holds no tables, calls engine services in-process, and integrates through registries and filters rather than monkey-patching. Card data never enters Livewire state; order placement uses a signed one-time token to prevent double submits; sensitive actions are rate-limited; HTML from store owners is sanitized through htmLawed; download and stream links are short-lived signed URLs. There is a Pest 4 + Playwright browser suite covering browsing, cart, guest and registered checkout, accounts, keyboard flows, and an axe check on every screen, plus a translation lint in CI and a release process that refuses to publish unsigned or CHANGELOG-discrepant tags.

To design and content: Every screen is also an embeddable Livewire component with a configurable layout, and the package ships editable product, category, cart, and checkout templates and patterns through the visual editor when installed. Accessibility is baseline, not a retrofit.

Risks to name openly: version 1.0 is new — plan a hardening sprint against our own catalogs, payment flows, and locale edge cases before a revenue-critical launch. The known accessibility issues in artisanpack-ui/livewire-ui-components markup should be tracked and either upstreamed or patched in our theme. The verified-email requirement for claiming guest orders and the account-creation action at checkout are policy decisions to confirm with legal/marketing before go-live.

Ask: Approve the adoption spike on staging (install command, config publish, Stripe test gateway, one locale beyond English) and confirm the commerce roadmap dates against this v1.0.0 baseline.