Statamic Marketing Toolkit Laravel Package

Technical Evaluation

Architecture fit. This is a Statamic addon, so it presumes a Statamic-flavored Laravel application (flat-file content, Antlers templates, addon service provider registration). It will not drop into a plain Laravel app or a Laravel app using a database-backed CMS — the integration surface is Statamic's content pipeline and tag/fieldtype system, not generic Eloquent models. Confirm the target application is on Statamic 4/5 before spending estimation time.

Integration feasibility. Low-friction for a Statamic site: composer require, publish config/assets, enable the addon. The v0.29.1 change ("llms.txt keeps its order between builds") is a deterministic-output fix in a generated artifact, not an API change — the upgrade note is explicitly "Nothing to do." That is the best possible signal for a patch bump, and it implies the maintainer is responsive to correctness defects in generated output rather than only shipping features.

Technical risk. The dominant risk is version maturity, not this release. The package is at 0.29.x: pre-1.0, high release cadence (29 minor bumps implies a still-moving surface), and no semver guarantee that a 0.x minor bump won't break configuration keys, Blade/Antlers tags, or generated file formats. A TPM should treat "pin the exact version" as a hard requirement, not a suggestion. Secondary risks: single-maintainer project (Jotham-LEC), unclear test coverage, and the generated llms.txt being a public-facing artifact whose format is still being standardized — output shape may change as the convention evolves.

Key questions. What Statamic and Laravel version range is supported? Is the llms.txt route cached/CDN-served, and does the ordering fix affect any cached copies already deployed? What is the test suite and CI posture? Is there a published support policy or 1.0 roadmap? Who else depends on this addon in our portfolio?

Integration Approach

Stack fit. Requires PHP/Laravel as dictated by the Statamic version in use, plus composer-based dependency management. It occupies the SEO/marketing-output layer (llms.txt, and by inference related generated marketing artifacts) — a side-effect surface rather than a request-path critical component, which keeps blast radius small if the addon misbehaves.

Migration path. Greenfield install. Since there is no prior assessment and presumably no existing integration, this is an adoption decision, not an upgrade. If the addon has been trialed already, the 0.29.0 → 0.29.1 step is a no-op: bump the lockfile, run the build, and diff the generated llms.txt to confirm ordering is now stable.

Compatibility. Verify the addon's declared Statamic constraint against the app's pinned Statamic version and against the next planned Statamic upgrade. Pre-1.0 addons frequently lag CMS majors; if a Statamic upgrade is on the roadmap within two quarters, budget addon-upgrade effort or a fallback (hand-rolled route/template) into that workstream.

Sequencing. (1) Confirm Statamic/Laravel compatibility. (2) Spike in a non-production environment: install, generate output, snapshot the artifact. (3) Pin the exact version in composer.json and lock it in CI. (4) Add a build-time diff check on generated output so any future ordering or format change surfaces as a reviewable delta. (5) Ship to production behind the existing marketing page release process.

Operational Impact

Maintenance. Low ongoing effort, but not zero: expect to review roughly monthly release traffic and to validate each 0.x minor bump because semver is not in force. Budget a recurring line item for "dependency bump + output diff" rather than assuming silent updates.

Support. Single-maintainer, community-supported OSS. There is no vendor SLA. If the maintainer goes quiet, the fallback is straightforward: the addon generates a static text artifact, so it can be reproduced with a Laravel route and a template. Keep the generated output format documented internally so that fallback stays cheap.

Scaling. Negligible runtime cost — this is build/render-time content generation, not a per-request hot path, provided the output is cached or statically served. No capacity planning implications.

Failure modes. (1) A Statamic major upgrade breaks addon compatibility → missing or malformed llms.txt (SEO/discoverability degradation, not an outage). (2) Non-deterministic output causes noisy diffs or spurious CDN cache invalidation — the exact class of bug v0.29.1 fixes. (3) A 0.x minor bump changes a config key silently → addon enabled but generating nothing; detect via a smoke assertion on the generated file in CI. (4) Malformed output served publicly; mitigate with a schema/format check before publish.

Ramp-up. Minimal — an engineer familiar with Statamic config and Antlers can integrate in under a day. The real onboarding cost is institutional: recording why the version is pinned and what the fallback is, so the next owner isn't re-deriving it.