Statamic Peak Tools Laravel Package

Product Decisions This Supports

• Starter-kit standardization (the real decision). This package is not adopted on its own merits — it ships as a dependency of the Statamic Peak starter kit. The actual product decision is "do we standardize new content/marketing sites on Statamic + Peak?" This library is a line item in that evaluation, not a candidate of its own.
• Build vs. buy vs. inherit for templating glue. The package exists to hold shared Antlers tooling reused across Peak's templates. If your team would otherwise write and maintain an internal helper library of Antlers tags/modifiers/partials, inheriting this is roughly a "buy" at zero marginal cost. If your helpers are already mature, this is a downgrade.
• Time-to-first-page on agency/portfolio delivery. For teams shipping many similar brochure, marketing, or content sites, Peak's opinionated defaults (Tailwind-flavored, Antlers-first) compress the discovery-to-first-template phase. That is a delivery-velocity decision, and this package is part of what you get.
• Roadmap scoping for shared design-system work. Choosing Peak means committing to its conventions rather than a bespoke component library. Decide upfront whether shared components live in Peak's structure, in your own layer on top, or in a fork — this decision is expensive to reverse after 5–10 sites.
• Dependency and licensing risk review. GPL-3.0 is unusual for a "helper" package and is a genuine decision input: it's fine for typical site delivery, but if you redistribute code, ship a commercial starter kit, or resell templates, it needs legal sign-off before adoption.
• Upgrade-cadence planning. With a small star count and tight coupling to Peak's release cycle, you're deciding to track a single upstream rather than a broad ecosystem. Budget for pinned versions and periodic manual review.

When to Consider This Package

Consider it when:

• You have already chosen Statamic and are evaluating or already using the Peak starter kit — in which case this arrives transitively and the only real question is whether to pin, vendor, or patch.
• You are an agency or in-house team delivering multiple similar Statamic sites and want opinionated, Tailwind-oriented defaults instead of a bespoke build.
• Your engineers are fluent in Antlers and comfortable reading upstream source when documentation is thin.
• You want a forkable, small-surface dependency rather than a supported enterprise library.

Look elsewhere when:

• You are not on Statamic, or you're using a different starter kit that already provides its own helpers — adding this would create duplicate conventions.
• You need a headless/API-first CMS posture; Peak's value proposition is server-rendered Antlers templates, not an API contract.
• You require vendor support, SLAs, or security-response commitments. Eleven stars and a single-maintainer lineage mean no support contract and a bus-factor of roughly one; treat this as vendored code you can own, not a third party you can lean on.
• GPL-3.0 is incompatible with your distribution or redistribution model (reselling templates, shipping a proprietary starter kit, client contracts with IP assignment and copyleft concerns).
• Your organization already has a mature internal component/templating layer — the migration cost and duplicated conventions will outweigh the savings.

How to Pitch It (Stakeholders)

To executives (one paragraph): This is a small internal helper library that arrives free with the Statamic Peak starter kit. It isn't a strategic purchase — it's a component of a stack decision we've already scoped. Its value is indirect: it trims boilerplate on every marketing site we template, which shows up as faster delivery on repeatable content sites rather than as a line-item saving. The risks are modest and manageable: single-maintainer project, minimal community, and a GPL-3.0 license we should clear with legal if we ever redistribute code. Recommendation: treat it as vendored code under our control, not as a critical third-party dependency.

To engineering: Comes in with Peak; provides shared Antlers tooling so you're not rebuilding common tags and modifiers per project. Practically, this means: pin the version, don't rely on upstream for fixes, and assume we may fork it. Read the source before depending on undocumented behavior, and keep our own helpers in a separate layer so an upstream change or abandonment doesn't cascade across client sites. Flag any GPL-3.0 implications for code we redistribute.

Bottom line for the decision log: Adopt only as a consequence of adopting Peak. Do not evaluate, procure, or build a roadmap around this package in isolation.