Inertia Statamic Laravel Package

Product Decisions This Supports

• Stack selection for content-driven apps: This package is the glue layer between Statamic (flat-file/Laravel CMS) and Inertia.js (SPA adapter for Vue/React). It directly informs the "Statamic + Inertia vs. headless CMS + separate API vs. plain Blade" decision — adopting it removes a bespoke integration from your build estimate.
• Build vs. buy on integration glue: Without it, engineering owns routing, controller responses, and page-prop serialization between Statamic content and Inertia components. This package is the "buy" (well, adopt) option for that thin but non-trivial layer.
• Roadmap sequencing for SPA front-ends: It enables an incremental path — ship content models in Statamic first, then layer an Inertia front-end without re-platforming. Useful when you want CMS value early and SPA polish later.
• Use cases it unlocks: marketing/content sites, docs portals, brochure sites with interactive islands, internal tools where editors need a friendly CMS but the front-end team wants a component-driven SPA.
• v0.2.1 signal — routing correctness: "Use actual lookup so we don't 404" is a defect fix in the request/route resolution path. For a PM this is a reminder that at 0.2.x the routing contract is still being stabilised; bake in regression testing for deep links and 404 handling if you adopt now.
• Project health signal: A first-time external contributor (@edalzell, PR #8) is a weak-but-positive community signal. Combined with a 0.2 → 0.2.1 patch cadence, it suggests active maintenance but a very small contributor base — treat bus-factor as a real risk item on the dependency register.

When to Consider This Package

Adopt (or prototype) when:

• You are already committed to Statamic as the CMS and want a Vue/React SPA via Inertia rather than server-rendered Blade.
• Your team is comfortable with pre-1.0 dependencies and can pin versions plus absorb occasional breaking changes on minor bumps.
• The integration surface you need is thin: content retrieval, page props, routing. You are not asking it to own auth, search, or complex form workflows.
• You can afford to own the risk: fork-and-patch capability in-house, and a documented fallback (write the glue yourself) if the package stalls.
• You want to ship a content site quickly and are willing to accept Statamic's commercial licensing alongside this MIT-ish community layer.

Look elsewhere when:

• You need a stable 1.0 API contract or vendor-backed SLAs — this is community-maintained at 0.2.x.
• Your architecture is headless-first: a REST/GraphQL content API consumed by a decoupled SPA is a better fit than Inertia's server-driven page-prop model.
• You require SSR/SEO guarantees out of the box — Inertia SSR adds its own operational overhead; evaluate before committing.
• You are not on Statamic. This package's value is entirely contingent on that CMS choice; it is not a general Inertia utility.
• The 404/route-lookup class of bug is a blocker for your use case (deep-linked marketing pages, campaign URLs) and you cannot wait for hardening.

How to Pitch It (Stakeholders)

For executives: This is a small open-source connector that lets our CMS (Statamic) feed a modern single-page front-end without us building and maintaining that bridge ourselves. It reduces initial engineering effort and keeps the content team on a familiar editing experience. The trade-off is maturity: the project is at v0.2.1, actively maintained but essentially single-maintainer with one recent outside contribution, so we should treat it as a calculated dependency rather than a foundation. Recommendation: pilot on one low-risk property, pin the version, and revisit at 1.0 or if maintenance activity lags.

For engineering: v0.2.1 is a patch fixing an incorrect lookup that produced spurious 404s — no API changes, no deprecations, safe to bump. It confirms the routing layer is still being shaken out, so add integration tests around deep links and not-found handling. Plan for version pinning and a documented exit path (in-house glue or a fork) given the pre-1.0 status and limited contributor base.