Statamic Frontend Grid Fieldtype Laravel Package

Product Decisions This Supports

• Platform upgrade sequencing. The only substantive change in 1.0.0 is Statamic 6 support. For a PM, that makes this release a compatibility marker, not a feature win: if Statamic 6 is on the roadmap, this dependency is no longer an upgrade blocker; if we're staying on Statamic 5, our usable ceiling is 0.0.4 and that branch will drift out of support. Either way this feeds directly into the "when do we migrate" decision.
• Build vs. buy for editor-facing authoring UI. A grid/repeatable-block fieldtype is deceptively expensive to build: a Control Panel component, validation, serialization, and a maintenance obligation across every future Statamic major. Buying (via Composer, free) trades that for an upgrade-testing task each major release.
• Editorial self-serve / roadmap. Where it fits, it reduces dev tickets for layout and repeatable-content changes by letting content teams compose grid-style content themselves rather than requesting template work.
• Vendor-risk input. 0.0.x → 1.0.0 with a changelog containing exactly one line ("Statamic 6 update") tells us maintenance here is upstream-driven and reactive. That's a legitimate factor in whether this package sits on an editor-critical surface or a peripheral one.
• Release-note thinness is itself a signal. No features, no deprecations, no migration guide. Treat 1.0.0 as "same product, new platform floor" until verified in staging — don't let the major version number imply behavior change in either direction.

When to Consider This Package

Adopt when:

• You are on, or committed to, Statamic 6 and need grid/repeatable-block authoring for content that renders in a frontend context.
• You want a Composer-installable fieldtype rather than a bespoke Control Panel component your team must own.
• The gap is narrow and specific — this is a fieldtype, not a page builder. Adopt it to fill one slot, not to define your content model.
• You can tolerate a single-maintainer dependency: lockfile pinning, an upgrade test in CI, and a willingness to fork if maintenance lapses.

Look elsewhere / hold when:

• You are on Statamic 5 with no near-term upgrade path. 1.0.0 targets Statamic 6; you'd be stranded on 0.0.4 with no expectation of future fixes. That's a support risk, not just an inconvenience.
• You need an SLA, guaranteed support windows across N and N-1 Statamic majors, or documented migration guarantees. None of that is on offer here.
• You need a full block library or page-builder experience — evaluate Statamic's native Grid/Bard plus first-party addons, or a commercially supported builder, instead.
• You already evaluated the 0.0.x line and passed. There is no new functional reason to reconsider; the merits haven't changed, only the platform floor.

How to Pitch It (Stakeholders)

Executives: A small free Laravel/Statamic addon that lets editors assemble repeatable, grid-style content in the CMS instead of filing dev tickets for layout changes. Version 1.0.0 is a compatibility release — it moves the addon onto Statamic 6 and, by going to 1.0, signals API stability. No new features, no documented breaking changes. The decision it forces is about platform timing, not new capability: if we're going to Statamic 6, this dependency stops being a blocker; if we're not, we pin to 0.0.4 and accept it will fall out of support.

Engineering: 1.0.0 is Statamic 6 support only — a single PR, one line of changelog. Read the major bump as an API-stability claim, not a feature release: verify in staging, check nothing depends on 0.0.x internals, and confirm our Statamic version constraint before bumping. Single-maintainer package — pin exact versions, keep an upgrade test in CI, and budget the option to fork.