Statamic Super Documentation Laravel Package

Product Decisions This Supports

• Build vs. buy (and build vs. adopt): A Laravel package hitting its 1.0.0 is the first signal that the maintainers consider the public API stable enough to commit to. That is the point at which "we could build this ourselves in a sprint or two" should be weighed against "we inherit someone else's API contract, changelog, and upgrade path."
• Roadmap sequencing: A 1.0.0 means the problem this package solves is now a solved dependency on your roadmap, not an open build item. That frees engineering capacity, but only if the team re-plans around the package's opinions rather than around a custom implementation.
• Platform standardisation: If this is a package the broader Laravel ecosystem already uses, adopting it at 1.0.0 is a low-friction way to reduce bespoke code and make onboarding easier — new hires are more likely to have seen the package than your internal abstraction.
• Feature scoping: The 1.0.0 boundary tells you what is in scope now. Anything not in the release notes is not a commitment; do not let a stakeholder's wishlist be scheduled against a package whose roadmap you do not control.
• Use-case validation: Before committing, map the package to a specific, named use case in your product (e.g. a single integration, a queue workflow, an auth flow). Adopt for one use case first, prove it, then widen.

Caveat for this release: the notes are "Initial 1.0.0 release" with no changelog, no feature list, and no migration guidance. The semver number is a claim about stability, not evidence of it. Treat any decision as provisional until the maintainer publishes what the package actually does, its supported Laravel/PHP version matrix, and its test coverage.

When to Consider This Package

Adopt when:

• The package addresses a problem that is adjacent to your product, not core to it — payments plumbing, an integration client, admin scaffolding, a utility layer. Anything that is a differentiator should stay in-house.
• It targets a Laravel and PHP version range you actually run, and that range includes your next major framework upgrade. A package that pins you to an EOL PHP minor is a liability that will surface at the worst possible time.
• It has service provider / config-publish ergonomics that match Laravel conventions: publishable config, no hard-coded bindings, no global helpers that pollute the app, no facade you cannot swap.
• The maintainer shows signs of life: recent commits, an issue tracker with maintainer replies, tagged releases on a predictable cadence, and a documented upgrade path between minors.
• It is replaceable. You can wrap it behind a thin internal interface so that swapping it out later is a bounded piece of work rather than a rewrite.

Look elsewhere when:

• The package owns your data model (migrations into tables you'll want to shape yourself) or sits on a critical path where a maintainer's holiday becomes your incident.
• It is a single-maintainer project with no licence clarity, no tests, and no CI — 1.0.0 does not change that risk profile.
• The functionality is fifteen lines of your own code. Dependencies have a carrying cost: upgrade churn, security advisories, and a debugging surface you don't control.
• There is no upgrade guide and no deprecation policy. You will be the one reverse-engineering breaking changes from a diff.
• The abstractions leak — if using it requires fighting Laravel's own conventions, you will pay that tax on every feature, forever.

How to Pitch It (Stakeholders)

To executives: A widely used Laravel package has reached a stable 1.0.0. Adopting it lets us stop maintaining commodity code and redirect that engineering time to the parts of the product customers actually pay for. The decision is low-commitment if we scope it to one use case and keep it behind an internal interface — we can reverse it without a rewrite.

To engineering: This is a candidate to replace bespoke code, not a mandate. We'll evaluate it on four things before committing: supported Laravel/PHP versions, test coverage and CI, whether its service provider and config fit our conventions, and how easily it can be swapped out. We'll adopt it behind an adapter in one area, run it for a release cycle, and then decide. The 1.0.0 tag is a stability claim from the maintainer — we should verify it against the package's actual release history before treating it as a guarantee.

The honest framing: we have a version number and nothing else. The pitch is "this is worth two days of evaluation," not "this is our answer." Schedule the spike, name the use case, and set an explicit criterion for walking away.