Fathom Laravel Package

Technical Evaluation

What the package actually is. Despite the "Laravel/PHP package" framing, aerni/statamic-fathom is a Statamic control-panel addon whose scope appears to be a single, narrow convenience: surfacing a link (likely a nav item or utility) from the Statamic CP to a shared Fathom Analytics dashboard. There is no analytics ingestion, no API client, no data pipeline, and almost certainly no persistence. The README title — "Easily navigate to your shared Fathom site" — is a reliable signal that the entire feature set is a configured hyperlink plus whatever CP chrome Statamic's addon scaffolding provides. v1.2.0 does not change this: it is a compatibility release, not a feature release. The value proposition is identical to the version originally assessed.

Architecture fit. For a Statamic-based stack this fits cleanly by construction: it will register a service provider extending Statamic\Providers\AddonServiceProvider, declare a CP nav/utility, and read a config value for the Fathom share URL. It sits at the outermost edge of the architecture — presentation layer only. That is a genuine strength for risk purposes (nothing to break in the request lifecycle) and a genuine weakness for value purposes (nothing a documented bookmark or a two-line custom nav item couldn't replicate). If the team is not on Statamic, the package is simply inapplicable; there is no Laravel-generic surface to reuse. Unchanged by v1.2.0.

Integration feasibility. Effectively trivial. Expect composer require aerni/statamic-fathom, php artisan vendor:publish for the config, one env/config entry for the Fathom site URL or share token, and a CP refresh. No migrations, no queue workers, no scheduled tasks, no middleware, no published assets requiring a build step beyond what Statamic's addon autoloading handles. Realistic effort: under an hour including review. One new precondition: confirm the estate is on Statamic 5. On Statamic 4, v1.2.0+ is uninstallable by design (see below), so "integration feasibility" is now version-gated rather than merely version-sensitive.

Technical risk. Still low in absolute terms, and materially lower than the prior assessment on the single highest-ranked risk. v1.2.0 directly retires the "may not declare support for the Statamic version currently in the estate" concern for Statamic 5 estates, and — more importantly — demonstrates that the maintainer is alive and tracking Statamic majors, which was previously inferred only from a stale 2024-05-14 release. That is a meaningful positive signal for a 3-star, single-maintainer package. But the release introduces a new risk shape:

• (a) Hard major-version cutoff, not a compatibility window. "Drop support for Statamic 4" is a one-way door. Statamic 4 remains upstream-supported, and any estate still on it is now frozen at 1.1.x, receiving no fixes, no security patches, and no CP-refactor accommodations — while the maintainer's attention has visibly moved to v5. This is the classic "last version before abandonment" pattern and should be tracked explicitly if any property in the estate is on Statamic 4.
• (b) Semver discipline. Dropping a framework major in a minor bump (1.x → 1.2.0) rather than a major is a versioning-policy smell. In practice Composer will hold Statamic 4 projects at 1.1.x via the transitive statamic/cms constraint, so it's not immediately dangerous, but it tells you the maintainer does not treat support-surface changes as breaking. Ask their policy; pin exactly rather than floating.
• (c) Single-major support only. The addon now supports Statamic 5 and only Statamic 5. There is no dual-support branch. Every future Statamic major will produce the same binary cut, meaning the upgrade-blocking failure mode recurs on a known cadence.
• (d) Unverified CI. The release note states support; it does not evidence a tested matrix. "Add support for Statamic 5" may be a constraint edit plus a smoke test, or a genuine CI-validated pass. This remains unconfirmed and is the single question most worth asking.
• (e) Unchanged residual risks from the prior assessment: abandonment, CP-surface fragility across Statamic majors, share-token exposure classification, and the trivial-value/high-perceived-cost asymmetry.

Key questions for the maintainer/review.

1. Which exact Statamic 5.x and Laravel major versions are supported, and is that combination exercised in a CI matrix (or is 1.2.0 a constraint-only change)?
2. Is there a maintenance branch for 1.1.x on Statamic 4, or is v4 support permanently ended? If permanently ended, what is the notice policy for future majors?
3. What is the semver policy — will future support-surface changes also land in minors?
4. Does it store or transmit the Fathom share token, and is the link rendered server-side or in a Vue component (i.e. is the token exposed to the client either way — it is a share token, so treat it as semi-public)?
5. Is CP visibility gated by Statamic permissions/roles, or visible to all CP users?
6. Does it use Fathom's API at all, or is it purely a hyperlink?
7. Does the v5 support path handle multi-site installs (per-site Fathom URL)?

Integration Approach

Stack fit. Requires Statamic 5 as of v1.2.0. Laravel version follows transitively from Statamic's own constraint. Confirm the exact statamic/cms version pinned in composer.lock before anything else — this now determines whether you are evaluating v1.2.0 (Statamic 5) or an end-of-line v1.1.x (Statamic 4). If the estate is Statamic 4, the decision is no longer "adopt or build" but "build, or accept a frozen dependency."

Migration path. No schema, no backfill, no dual-write. "Migration" means: install, publish config, set the Fathom URL, verify the CP nav entry renders for an authorized user, add to the addon inventory. Rollback is composer remove with zero cleanup. New wrinkle: if any install is mid-upgrade from Statamic 4 to 5, the package must move with the framework upgrade rather than independently — sequence the Composer constraint bump as part of the Statamic major upgrade PR, not as a separate change, so the addon never blocks the framework bump.

Compatibility. Two axes: (1) addon constraints against the pinned Statamic version — now explicitly ^5.0, so a Statamic 4 project will silently sit on 1.1.x unless the constraint is pinned deliberately; (2) CP nav item rendering under the project's CP customizations (custom nav, nav groups, cached nav) — this is the surface most likely to differ between Statamic 4 and 5, and the release notes give no detail on what changed. Also confirm behaviour in local/dev where Fathom may be unreachable: the link should degrade to a dead link, not an exception on CP boot.

Sequencing.

1. Inventory check (hour 1): list every Statamic install in the estate and its statamic/cms version. Split into v5 (eligible for 1.2.0) and v4 (frozen at 1.1.x). This single step determines whether the assessment is a procurement or a code-cleanup exercise.
2. Composer spike (day 1): install 1.2.x on a branch against a Statamic 5 staging site, confirm resolution and CP render.
3. Upgrade-path test (day 1): in the same spike, exercise the actual Statamic 4→5 upgrade with the addon present, to confirm the addon is not the thing that blocks the framework bump.
4. Permission pass (day 1): decide who sees the link; if the addon doesn't gate by role, accept universal visibility or add an authorization check.
5. Config hygiene (day 1): share URL in environment config, not committed; document the variable.
6. Build-vs-buy decision (day 2): prototype the in-house equivalent (a NavItem/Utility in AppServiceProvider or a local addon reading a config value). Still likely under two hours.
7. Adopt or absorb (day 2): if adopting, pin exactly ("aerni/statamic-fathom": "1.2.*", not ^1.0 and not *) and record it in the dependency register with owner and review date aligned to the Statamic 6 cycle.

Recommendation. The prior recommendation — build-vs-buy with a strong prior toward in-house — stands, but softens at the margin. v1.2.0 is evidence of active maintenance, which was the largest single unknown; that removes the "may already be abandoned" objection. It does not change the underlying value (a nav link) or the dependency cost (a line item re-validated at every Statamic major). For a Statamic 5 estate, either path is defensible and the spike should decide on effort, not risk. For a Statamic 4 estate, prefer in-house outright: adopting a package whose maintainer has just publicly ended support for your framework version is a guaranteed future migration for a feature worth ~30 lines.

Operational Impact

Maintenance. Near-zero runtime maintenance; non-trivial dependency maintenance, now with a known cadence. v1.2.0 confirms the addon will produce a hard compatibility cut at each Statamic major (4→5 happened; 6 will happen the same way). That is better than silent rot — you can plan for it — but it means the maintenance event is scheduled and recurring, not hypothetical. Budget a small task at each Statamic major with an owner and a calendar entry; the work is either a constraint bump or a same-day fork/absorb.

Support. Support burden is "the link is missing" or "the link 404s," both diagnosable in minutes. Two new support shapes introduced by this release: (1) "why can't I install/update the package" on Statamic 4 — answer: by design, 1.2.0+ is v5-only; (2) frozen-dependency drift on v4 installs, where 1.1.x accumulates no fixes and nobody notices until an unrelated CP regression. Assign an owner in the addon register and note the version ceiling explicitly.

Scaling. Not applicable in any meaningful sense: no queries, no jobs, no per-request public-site cost. Scales to any traffic because it does nothing at request time. The only scaling consideration remains organizational — multi-site or multi-brand installs may need per-site Fathom URLs, which a single config value may not accommodate, and v1.2.0 gives no signal that multi-site was addressed. Verify if the estate is multi-site.

Failure modes. Ranked by likelihood, updated for v1.2.0:

• Upgrade gate at the next Statamic major — Composer refuses to install; blocks the framework upgrade until the addon ships, is forked, or is removed. This is now a known, scheduled event, not a surprise. Highest-probability failure, and the one to design around.
• Statamic 4 estates pinned to 1.1.x — no failure event, just a silent end-of-life dependency. Newly introduced by this release.
• CP nav item renders broken or throws after a Statamic CP refactor — degrades the user-facing control panel; treat as P2. Statamic 5 is exactly such a refactor, so inspect the CP after the spike rather than assuming the release note covers it.
• Stale/wrong Fathom URL — silent, user-reported, trivial fix.
• Share token exposure — token embedded in the CP, possibly client-side; acceptable if intended semi-public, but confirm and document the classification rather than assuming.
• Abandonment — materially downgraded by this release, but not eliminated. One release after a long gap is a pulse, not a heartbeat; watch the next Statamic major as the real signal.

Ramp-up. Fifteen to thirty minutes for an engineer familiar with Statamic addons; a few hours for someone unfamiliar, most of it spent on Statamic's addon registration docs rather than this package's code. The codebase remains small enough to read end-to-end before trusting it — do so, especially the v4→v5 diff, which is where any behavioural change will hide. Documentation is a few lines of README; assume no runbook and write a two-line addon-register entry covering purpose, owner, supported Statamic version (5 only), config variable, and removal steps.

Bottom line for a TPM. v1.2.0 is a maintenance release that answers the most important open question — is this thing maintained? — affirmatively, and should be read as a modest strengthening of the case for adoption. It does not change the value (negligible), the runtime risk (negligible), or the dependency cost (a recurring line item at each Statamic major). Decision rule: Statamic 5 estate → time-boxed spike, either outcome acceptable, pin exactly. Statamic 4 estate → build in-house; do not adopt a package that has just ended support for your framework. In both cases, keep the strong prior toward absorbing ~30 lines of nav registration and keeping the dependency count flat.