Statamic Laravel Package

Product Decisions This Supports

• Roadmap: content operations as a first-class capability. This package is the plumbing that lets marketing, merchandising, and brand teams publish landing pages, campaign pages, and navigational structure in Statamic while the Rapidez storefront renders them natively. It supports a roadmap commitment to "content velocity without engineering tickets," a common ask once a storefront ships and every campaign becomes a deploy.
• Build vs. buy: buy the adapter, own the presentation. The integration surface — exposing Statamic entries and globals to Rapidez, CMS-driven routing, navigation, and reusable content blocks — is undifferentiated glue code. Rebuilding it buys nothing competitively. The differentiated work (component library, page templates, brand system) stays in-house either way. This package is the cheaper side of that split.
• Use case: campaign and seasonal pages. Time-boxed promotional pages are the highest-volume, lowest-reuse content in e-commerce. Routing CMS entries through Rapidez's existing router means campaign pages ship on a content calendar instead of an engineering sprint.
• Use case: navigation and merchandising surfaces. CMS-managed navigation, mega-menus, and reusable blocks (banners, teasers, editorial strips) are high-churn, low-logic surfaces. Centralizing them in a CMS reduces the blast radius of small copy and layout changes.
• Use case: editorial adjacency. Blog, buying guides, and brand storytelling can live beside the catalog rather than on a separate domain — a real SEO and conversion argument, and one this package enables without a second frontend.
• Architecture decision: headless CMS, not monolithic Magento CMS. If the roadmap includes multi-store, multi-locale, or content reuse across channels, choosing a dedicated CMS layer now avoids a migration later. This package is the concrete embodiment of that bet for Rapidez-based storefronts.
• Licensing decision: GPL-3.0 is a product-level call, not a legal footnote. For a self-hosted or client-distributed storefront, copyleft obligations can constrain how you ship. Confirm with legal before it becomes an architectural dependency.
• Vendor concentration decision: Statamic becomes a second platform to operate. Statamic Pro licensing, upgrades, and content-model governance are real ongoing costs. The decision to adopt this package is implicitly the decision to run two systems.

When to Consider This Package

Adopt when:

• You are already on Rapidez. This is a Rapidez-specific adapter; outside that stack it has no value. Its entire proposition is bridging Statamic content into Rapidez's routing and data layer.
• You are on Laravel and Statamic or willing to be. Statamic's flat-file model and Laravel-native architecture are the reason this integration is small; mixing in a different CMS defeats the purpose.
• Marketing owns a meaningful share of the page surface — campaigns, landing pages, navigation, reusable blocks — and engineering is currently the bottleneck on those changes.
• You have in-house Laravel capability and are willing to own the dependency. With single-digit stars and no dependents, treat this as source you may need to fork and maintain, not a vendor product.
• Cache-friendly delivery matters to you. The package advertises cache-friendly content delivery, which aligns with storefront performance budgets where page latency is revenue.

Look elsewhere when:

• You are not on Rapidez. Evaluate the native Statamic frontend, a different storefront (Hyvä, PWA Studio, Next.js commerce), or a different CMS. Do not adopt this as a reason to move to Rapidez.
• You need an enterprise support contract, SLA, or a large ecosystem of adopters. Four stars and zero dependents is a genuine maturity signal. If procurement requires referenceable customers or vendor indemnity, this fails that bar.
• GPL-3.0 conflicts with your distribution model. If you ship storefront code to clients or as a product, get legal sign-off first — or plan for a different integration path.
• Content needs are shallow and stable. If you need a handful of static pages a year, Magento's built-in CMS or hardcoded templates are cheaper than operating a second platform.
• You need deep product-content coupling — per-SKU rich content, spec tables, or PDP composition driven by merchandising rules. That belongs in the commerce/PIM layer, not a page CMS. This package's scope is pages, navigation, and reusable blocks, not catalog enrichment.
• You expect a turnkey page builder. This is a data-and-routing bridge. Frontend components, page templates, and editor UX still need to be designed and built.

How to Pitch It (Stakeholders)

For executives — the one-paragraph version: Our storefront currently requires engineering work for every marketing page. This package connects our storefront to Statamic, a content management system, so marketing can publish campaign pages, navigation, and reusable content blocks on their own schedule while the storefront renders them natively. It is a small integration layer, not a new platform to build. The upside is content velocity and fewer engineering interrupts; the cost is a Statamic license, a second system to govern, and a young open-source dependency we should expect to support ourselves. Recommend a bounded pilot on campaign pages before committing the full content surface.

For engineering — the technical framing: This is an adapter between Rapidez's routing/data layer and Statamic's content repository. It exposes entries and globals to the storefront, resolves CMS-driven routes, and surfaces reusable blocks — leaving our Vue/Inertiai presentation layer untouched. It is Laravel-native, so it fits our existing deployment and caching story. Two caveats to size honestly: the project is early (minimal adoption, no dependents), so assume we may fork and maintain it; and it is GPL-3.0, which needs a legal read before it spreads beyond a pilot. Scope the pilot to routing, navigation, and one reusable block type to validate the abstraction before we invest in templates.

For marketing — the operational promise: You get direct control over campaign pages, navigation, and promotional blocks without filing engineering tickets, and without leaving the storefront experience. Content changes ship on your calendar. The trade-off is that you own content modeling and publishing discipline — the CMS is only as useful as the structure we agree on up front.

For legal and procurement — the flags: GPL-3.0 copyleft obligations need review against our distribution model. Statamic carries its own licensing tier for some features. And the dependency is immature enough that we should document an exit or fork plan rather than assume upstream support.