Core Laravel Package

Product Decisions This Supports

• Headless commerce go/no-go. Choosing rapidez/core is effectively a commitment to a decoupled Magento/Adobe Commerce storefront with a Laravel BFF in front of it. This is the moment to decide whether the current Luma/blank-theme storefront is a constraint worth removing, and whether the commerce backend stays put while the experience layer is replaced.
• Build vs. buy for the integration layer. The package supplies the plumbing you would otherwise build: Magento GraphQL client, Eloquent-style models over commerce data, caching, routing, config and middleware. That reframes the roadmap conversation from "build an integration platform" to "build differentiating storefront experiences" — a multi-quarter scope reduction.
• Team shape and hiring. A Laravel/PHP core means the existing backend team can own storefront delivery. This is a hiring and budget decision as much as a technical one, and it usually beats standing up a separate Node/React practice for a mid-size catalog.
• Roadmap sequencing. Because routing, data access and caching are handled, prioritization can start at revenue-critical flows — category/PLP, PDP, search, cart, checkout hand-off — rather than at foundational infrastructure. Plan the first release as a thin vertical slice, not a platform build.
• Multi-store, multi-currency and localisation decisions. Frontend-per-market versus shared frontend with configuration is a product-architecture call the BFF layer directly enables or constrains.
• Performance and Core Web Vitals commitments. A server-rendered Laravel frontend plus caching gives a credible answer to marketing's speed and SEO requirements; treat the performance budget as a product requirement the architecture must be validated against, not assumed.
• Licensing and distribution strategy. GPL-3.0 is the decision most likely to be overlooked. If the storefront is operated for your own brand, the practical exposure is low. If you white-label, resell, or distribute the storefront to merchants, the copyleft obligation materially changes the commercial model. Get this settled before the roadmap is socialised.

When to Consider This Package

Consider it when:

• Magento or Adobe Commerce is already the system of record. The package's value is concentrated in that integration; without a Magento backend it is the wrong tool.
• PHP/Laravel capability exists in-house or in your agency. The productivity argument collapses if the team is React-first.
• Time-to-market dominates. You want a credible storefront in weeks, with the option to differentiate selectively rather than rewrite the commodity layer.
• A single-vendor-ish ecosystem is acceptable. You are comfortable depending on a small upstream and tracking its releases, rather than on an Adobe-owned roadmap or a large commercial vendor with an SLA.
• GPL-3.0 is compatible with your distribution model after legal review.

Look elsewhere when:

• The commerce backend is Shopify, commercetools, BigCommerce or a custom service — the integration is the product here.
• You need contractual indemnification, an enterprise support tier, or a large hiring pool. Vue Storefront, Front-Commerce, or Adobe's own PWA Studio are the comparison set for those requirements.
• You intend to ship a closed-source or white-labelled storefront product to third parties; the licence makes that a legal project, not a packaging decision.
• The storefront is a small, low-traffic marketing-led site where the existing theme plus incremental improvements is cheaper than a platform change.

Diligence note: the package-level repository signal is thin (17 stars, low opportunity score). That almost certainly reflects a monorepo split rather than ecosystem health — but do not take it on faith. Before committing, verify the parent Rapidez repository's activity, Packagist download trends, release cadence against Magento versions, open-issue responsiveness, and whether you can name at least two production references outside the vendor's own portfolio.

How to Pitch It (Stakeholders)

To executives: We can replace the storefront experience without replacing the commerce platform. rapidez/core gives us the integration layer that would otherwise consume a quarter or more of engineering, so budget goes to merchandising, conversion and brand experience instead of plumbing. It runs on Laravel, which our team already knows, so we avoid both a new platform licence and a new frontend practice. The software itself is free; the two things to approve are a short technical spike and a legal read on the GPL-3.0 licence, because it affects any plan to resell or white-label the storefront later.

To engineering: This is an idiomatic Laravel package — GraphQL client, models, caching, routing and configuration — that lets us treat Magento as a data source rather than a rendering engine. It is testable and debuggable with the tooling we already run. The trade-off is dependency on a small upstream: pin versions, read the changelogs, budget for upgrade work at each Magento release, and keep our customisations in our own namespace so we can absorb upstream changes. Treat the spike as an evaluation of upgrade ergonomics, not just of feature coverage.

To finance: No licence fee and no per-seat cost. The real line items are the migration effort, the ongoing upgrade cadence, and — if we ever distribute the storefront — the implications of a copyleft licence. Model three years of total cost against the alternative of rebuilding on a commercially licensed frontend, and include the cost of the PHP team we already have versus the team we would have to hire.

The ask: Two weeks, one engineer, one designer, one legal review. Ship a read-only vertical slice — category page and product page against the live catalog — measure build speed and page performance, and confirm the licence position. That gives us enough evidence to commit or walk away before the roadmap depends on it.