Findable Laravel Package

Technical Evaluation

Architecture fit. Despite being catalogued as a "Laravel/PHP package," elaniin/findable is a Statamic add-on, not a framework-level Laravel library. That single fact gates the entire evaluation: it is only relevant if the target application runs Statamic 3.x (Statamic itself runs on Laravel, so the Laravel dependency is transitive). For any non-Statamic Laravel application, an Inertia/SPA front end, or a headless CMS setup, this package is architecturally irrelevant. Within a Statamic 3 site, it fits the expected add-on shape: a service provider registered via Statamic's add-on manifest, likely contributing SEO fields/fieldsets to blueprints, control-panel configuration, and front-end meta output. That is a shallow, well-trodden integration surface — it decorates content rather than owning business logic.

Integration feasibility. Mechanically straightforward: composer require, auto-discovery or manual provider registration, publish config/assets, then attach SEO fields to collections and configure site defaults. Effort is configuration and content-modeling, not engineering. The real feasibility question is version constraint compatibility — whether the package's statamic/cms and laravel/framework constraints permit installation on the target's pinned versions. Last release was January 2022, which places it firmly in the Statamic 3 era (Statamic 4 shipped 2023, Statamic 5 in 2024). A ^3.0 constraint will hard-block installation on current Statamic regardless of code quality.

Technical risk.

• Maintenance risk (high). 13 stars, last release 2022-01-27, single-agency authorship. Treat this as effectively unmaintained; assume fork-and-own.
• Version risk (high). Statamic add-ons break across major versions because the add-on API, fieldtype contracts, and CP components change. No evidence of 4.x/5.x support.
• Duplication risk (medium-high). Statamic ships a first-party, commercially supported SEO add-on (SEO Pro). Adopting a low-adoption community alternative over a maintained first-party product needs a strong cost or feature justification.
• Data-model risk (medium). SEO metadata is typically stored in entry front-matter or a companion table. Whichever it is determines migration cost and whether data survives if you later swap add-ons.
• Security/supply-chain risk (low-medium). MIT, small dependency surface, but no visible security posture or audit trail.

Key questions to resolve before committing.

1. What Statamic/Laravel/PHP constraints does composer.json declare, and does it install cleanly on our pinned versions?
2. Is metadata stored in entry data (YAML front-matter) or a separate table — and what is the fallback if the add-on is removed?
3. Does it own sitemap/robots/canonical/redirect behavior, or only per-entry meta tags? The former is operationally heavier and more failure-prone.
4. Multisite support? Localization of meta fields? Static caching compatibility?
5. Any test suite, CI, or release cadence? Who is the accountable maintainer?
6. What does SEO Pro (or a 50-line custom fieldset) not cover that justifies this dependency?

Integration Approach

Stack fit. Valid only for Statamic 3.x on Laravel 8–10 / PHP 8.0–8.1-ish. Confirm the exact matrix empirically in a scratch environment before estimating anything. On Statamic 4/5 the realistic options are: fork and port (small surface, but you now own it), or adopt first-party SEO Pro / a custom fieldset.

Migration path. If replacing hand-rolled SEO fields or another add-on, inventory the existing field handles and data locations first, then map them into this package's expected blueprint fields. Blueprint changes generally require re-saving entries or a one-off migration to backfill defaults, so plan a content-touching migration rather than assuming fields "just appear." Preserve the old fields until the new output is verified in production HTML, not just in the control panel.

Compatibility and rendering. Verify interaction with Statamic's static caching and Laravel response caching — SEO tags rendered at request time can be stale or absent under aggressive caching. Check for Blade view overrides or published assets that could collide with theme templates. Confirm behavior under multisite (per-site defaults vs. shared config).

Sequencing.

1. Time-boxed spike (1–2 days): install, wire one collection, render meta tags, confirm sitemap/canonical behavior.
2. Comparative decision memo against first-party SEO Pro and a minimal custom-fieldset build, including total cost of ownership over 24 months.
3. If proceeding: pin an exact version (avoid ^ ranges), vendor/lock, and treat the fork as an internal dependency with a named owner.
4. Ship behind a per-site feature flag; validate rendered HTML and crawl behavior in staging.
5. Post-launch: automated checks asserting meta tag presence/uniqueness on key templates.

Operational Impact

Maintenance. The dominant cost is not adoption but stewardship. Plan for the package to be forked into the organization's namespace, with a documented patch policy and a review triggered by every Statamic major/minor upgrade. Budget roughly one to two engineer-days per Statamic upgrade cycle plus ad-hoc fixes. If that appetite doesn't exist, the honest recommendation is to not take the dependency.

Support. No commercial support, no SLA, community issues only. Internal escalation means fixing it yourself. That is acceptable for a decorative metadata layer; unacceptable if it ends up owning redirects or sitemap generation, where breakage is customer-visible.

Scaling. Runtime cost is negligible — it produces markup at render time. The scaling concern is editorial and configurational: every new collection, site, or locale needs SEO fields attached and defaults set, and sitemap generation on large content sets needs caching. Operational scale-out (multiple app nodes) is a non-issue provided config is deployed consistently.

Failure modes.

• Silent SEO regression: missing, duplicated, or incorrect canonical/noindex tags after an upgrade — the highest-impact failure because it degrades traffic without erroring.
• Version lockout: composer resolution failure on a Statamic upgrade, blocking the platform upgrade rather than the add-on.
• Caching staleness: tags served from cache after editorial updates.
• Template collision: overridden views or published assets interfering with theme rendering.
• Abandonment: no upstream fixes; the internal fork diverges indefinitely.

Ramp-up. Low. A Laravel developer with Statamic familiarity can be productive in under a day; the add-on conventions (fieldsets, blueprints, CP nav) are standard. The non-obvious knowledge is Statamic-specific content modeling and caching behavior, which the team likely needs anyway.

TPM recommendation. Treat this as a buy-vs-build-vs-first-party decision rather than an adoption. Given 13 stars, a 2022 release, no visible maintenance, and a supported first-party alternative, default to SEO Pro or a small custom fieldset unless the spike reveals a specific capability that justifies owning a fork.