Footprint Statamic Laravel Package

Product Decisions This Supports

• Feature scoping for sustainability/"footprint" surface area. If website or content footprint (carbon, page weight, or similar — the release does not yet document which) is on your roadmap, this addon is a candidate input to the "do we expose this in the CMS, and to whom (editors vs. end visitors)?" decision.
• Build vs. buy (vs. adopt). A v0.1.0 Composer addon is a "free to try, cheap to discard" option against building a custom reporting module or integrating a third-party measurement API. At this maturity it supports a spike, not a build-vs-buy commitment.
• Platform fit check. This is a Statamic addon (Statamic runs on Laravel), not a general Laravel package. The first real decision it informs is whether footprint functionality is relevant to your Statamic-based properties only, or whether you need a framework-agnostic solution.
• Client-facing differentiators. If you ship Statamic sites for clients with ESG/procurement questionnaires, this could underpin a "green hosting / low-carbon page" disclosure or badge — useful in sales collateral and RFP responses.
• Roadmap gating. Establishes a watch-list item: revisit when the addon reaches 0.3+/1.0, publishes a README with the actual metric definition and calculation methodology, and shows sustained commit activity.

When to Consider This Package

Adopt (trial, non-production) when:

• You already run Statamic 4/5 on Laravel and want footprint data surfaced inside the control panel rather than in a separate tool.
• You have an engineer who can read the source directly — v0.1.0 ships with a bare changelog link and no documented feature set, so the code is the documentation.
• You can pin an exact version, isolate the dependency behind your own interface, and accept breaking changes on any minor bump.

Look elsewhere when:

• Your application is Laravel-only (no Statamic) — the addon is irrelevant and a generic library or API integration is the right call.
• You need production SLAs, LTS support, a security review, or an audited calculation methodology — pre-1.0, single-maintainer, undocumented is disqualifying for anything compliance-adjacent.
• The number will appear in a regulatory or contractual disclosure. Use a vendor with a published, defensible methodology; treat any 0.1.0 addon as a UI/reporting layer over such a vendor at most.
• A maintained alternative exists in the Statamic addon marketplace with a documented changelog and version history — prefer it, and revisit this one later.

How to Pitch It (Stakeholders)

For executives: A zero- or low-cost, small-footprint experiment. It's an early (0.1.0), pre-stable addon for Statamic sites that would let editors see and act on a site's footprint from inside the CMS. The ask is one engineering spike — roughly 1–2 days — on a single non-critical property, not a production commitment. Upside is a credible sustainability story for client pitches and RFPs; downside is capped at the spike cost, because the addon is isolated behind our own interface and can be removed without touching product code. We should not cite any output from it externally until maturity, documentation, and methodology are established.

For engineering: Composer-installable Statamic addon, v0.1.0, no release notes beyond a changelog link — expect the public API to move. Pin the exact version, wrap all calls in a thin adapter so we can swap implementations, and don't let its data model leak into our domain. Validate the calculation against a known reference before anyone shows it to a client. Flag any migrations or published config/assets early; pre-1.0 addons frequently change those between minors.