Statamic Addon Laravel Package

Technical Evaluation

Architecture fit. This is a Statamic addon (Composer package, simplestats-io/statamic-addon) targeting Laravel-based Statamic installations. It slots into the standard Statamic addon lifecycle (service provider registration, config publishing, control-panel integration) rather than introducing a parallel architecture. For teams already standardized on Statamic + Laravel, the fit is native; for non-Statamic Laravel apps, it is not applicable.

Integration feasibility. Install path is conventional: composer require simplestats-io/statamic-addon, addon auto-discovery, publish config, and wire credentials. No bespoke build tooling is required by consumers — the v1.1.1 change is to the package's own build workflow, not to the consuming application's build.

Technical risk. Low for this specific release. v1.1.1 is a patch-level bump whose only noted change is "Build Workflow" (CI/release pipeline), with no stated runtime, API, or configuration changes. Risk therefore concentrates in the usual places for a young addon: thin release documentation, a single-maintainer/vendor dependency, and unverified behavior across Statamic major versions. The absence of a described changelog beyond CI means we cannot infer fixes from the release — treat v1.1.0 behavior as the functional baseline.

Key questions.

• Which Statamic major versions (and by extension Laravel/PHP versions) are supported, and is that captured in composer.json constraints rather than prose?
• Does the "Build Workflow" change alter published artifacts (e.g., dist archive contents, autoloader, excluded dev dependencies) in a way that affects installed installs?
• What is the actual feature surface — analytics ingestion, control-panel reporting, or both?
• Is the vendor's data-handling model (where events are sent, PII, retention) documented, and does it satisfy our privacy review?
• Support model: is this a paid/closed service tied to the addon, and what are the SLAs?
• Test coverage and CI posture as evidenced by the workflow itself (matrix breadth, static analysis, tagged releases).

Integration Approach

Stack fit. Requires a Statamic project on a supported Laravel/PHP baseline. Confirm the constraint set before committing; Statamic addons frequently lag the newest Laravel majors. No impact on front-end stack or hosting model beyond whatever outbound calls the addon makes.

Migration path. Greenfield installs are straightforward. For existing analytics tooling replacement, plan a parallel-run period: install the addon, keep the incumbent collector active, compare reported figures, then cut over. Because v1.1.1 is build-only, migration planning can proceed against v1.1.0 documentation without rework.

Compatibility. Pin to ^1.1 and commit the lockfile. Treat 1.x as the stable line; expect no breaking changes within it. Validate against our exact Statamic/Laravel/PHP triple in a staging environment rather than relying on the vendor's matrix. Check whether the addon publishes config and whether the control-panel assets are precompiled (a common friction point where the workflow change could matter).

Sequencing.

1. Vendor due diligence: license, support terms, data-processing terms, release cadence.
2. Constraint check in composer.json against our runtime.
3. Spike in a disposable environment: install, publish config, verify control-panel surfaces load.
4. Staging parallel run with the incumbent tool, with figures reconciled.
5. Production rollout behind a config flag; retain the incumbent for one reporting cycle.
6. Only then decommission prior tooling.

Operational Impact

Maintenance. Low ongoing effort if the addon is config-driven and the vendor ships regularly. Ownership sits with whoever owns the Statamic application — this should not become a second CMS-adjacent platform to maintain. Budget for periodic version-bump PRs (Dependabot/Renovate) and re-verification after Statamic major releases.

Support. Primary dependency is a small vendor. Escalation path is GitHub issues plus whatever commercial agreement exists. Assess the bus factor before making it load-bearing for reporting. Internal knowledge should be documented so an outage does not require the original implementer.

Scaling. Two dimensions: request-path overhead (any synchronous outbound call on page render is a latency and availability risk — prefer async/queued dispatch if the addon supports it) and analytics-side volume/queries. Confirm behavior under traffic spikes and whether failures are fail-open (site keeps serving) or fail-closed.

Failure modes.

• Vendor API outage: does the site degrade gracefully or surface errors to visitors?
• Credential/rotation expiry: silent data loss is the likely symptom — alert on ingestion gaps, not just exceptions.
• Build-artifact drift from the CI workflow change: a broken or unexpectedly scoped dist archive would only surface on fresh installs, so verify with a clean composer require in CI, not an incremental local update.
• Statamic upgrade breaking addon boot: addon service provider failures can take down the control panel.
• Data/privacy regression if event payloads change without notice.

Ramp-up. A Laravel-fluent engineer can install and configure in under a day; meaningful ramp-up is spent on the vendor's analytics semantics and privacy review, not the code. Allocate roughly a week of one engineer for due diligence, staging validation, and parallel-run reconciliation. Document the config surface and the vendor dependency in the runbook as part of the rollout — not after the first incident.

Note on this release. v1.1.1 is a build-workflow-only patch. It changes nothing we can evaluate functionally and does not alter the plan above; it slightly reduces release-process risk by showing an actively maintained CI pipeline. The assessment should be revisited when a release ships substantive features, deprecations, or breaking changes — or when the open key questions (version support, data handling, support model) are answered.