Statamic Dynamic Token Laravel Package

Product Decisions This Supports

• Build vs. buy (default to buy/evaluate): The arrival of a tagged, stand-alone v1.0.0 package is the decision point where "we could build this ourselves" becomes "we should timebox an evaluation instead." A standalone Composer package means no fork to maintain, no copy-paste into app/, and upgrades via composer update rather than a quarterly manual merge. That materially lowers total cost of ownership versus an in-house implementation.
• Feature scoping: A 1.0.0 release implies a deliberately bounded problem domain — the author has drawn a line around what the package does. Treat that boundary as the first draft of our scope: whatever the package covers, we should not be planning bespoke work for; whatever it doesn't, stays on our roadmap as a known gap.
• Roadmap sequencing: Because the package is versioned, we can plan adoption against a stable surface rather than chasing a moving target. This is the difference between "we'll slot this into next quarter" and "we can't commit to a date."
• Risk posture on dependency adoption: Standalone + 1.0.0 + semver is the cheapest possible integration risk profile for a third-party dependency. It's a low-ceremony trial: spike it behind a single internal interface, and if it disappoints, swap it out without touching domain code.
• Use cases to validate in the spike: Confirm the package's fit against our two or three real workflows — not a hello-world. The evaluation question isn't "does it work," it's "does it work on our data shape and our edge cases."

Evidence gap to close before committing: these release notes tell us about packaging maturity, not capability. "Completed stand-alone package" is a distribution milestone — it says nothing about feature surface, supported Laravel/PHP version range, test coverage, or maintenance cadence. The assessment below should be re-read once we have the README and a CI status badge; until then, treat capability claims as unverified.

When to Consider This Package

Adopt / evaluate when:

• The problem it solves is adjacent to your core domain, not inside it. Good candidate for buy; poor candidate if the functionality is your product differentiator.
• You're on a Laravel version the package declares support for, and your PHP version is within its constraint range. Verify the composer.json constraints before anything else — version-range mismatches are the most common reason a 1.0.0 package dies in evaluation.
• You need the capability now and can absorb an integration spike plus a documented rollback path.
• You want a stable, semver-governed dependency you can pin and upgrade on your own schedule.

Look elsewhere (or build) when:

• The package is a single-maintainer project with no test suite, no CI, and no release history beyond this one tag. A 1.0.0 with no prior tags is a packaging milestone, not necessarily a maturity milestone — check whether 0.x versions existed and how long they ran in the wild.
• Your requirements diverge from the package's apparent scope and you'd end up wrapping it so heavily that the wrapper becomes the real product.
• It sits on a critical path where a breaking change or an abandoned repo would be an incident. In that case, prefer a fork you control or an in-house build.
• Licensing or vendor terms are incompatible with your distribution model — check the license file, not the packagist summary.
• The package reaches into framework internals or global state in ways that will fight your existing service container, middleware, or multi-tenant setup.

Practical gate: no adoption decision until someone has (a) read the source, (b) run the test suite locally, and (c) confirmed the package's Laravel support matrix against ours. That's a half-day of engineering, and it's cheaper than any of the alternatives.

How to Pitch It (Stakeholders)

For executives — one paragraph: A dependency we've been tracking has reached its first stable release as a self-contained package. That changes it from a "someday" line item into a low-risk, low-cost option we can trial without committing engineering headcount. The pitch is deliberately modest: a short evaluation, a clear go/no-go, and no long-term lock-in, because it installs and uninstalls cleanly through our existing dependency tooling. I'm not asking for budget — I'm asking for a half-day of engineering time to produce a recommendation.

For engineering — the substance: This is now a standalone Composer package at v1.0.0, which means we get a semver contract, a clean install path, and no fork to babysit. Proposed approach: pin it, isolate it behind a thin internal adapter, and validate against our real workflows rather than a demo. Before we merge anything, we verify the PHP/Laravel constraints, run the upstream test suite, check release cadence and maintainer activity, and confirm the license. Success criteria: it handles our edge cases, the adapter is small enough to be worth having, and we could remove it in under a day if we needed to. If any of those fail, we walk — and we'll have lost half a day rather than a sprint.

Framing to avoid: don't sell this as "a new dependency" — dependencies read as risk to both audiences. Sell it as a bounded evaluation with a defined exit, which is what it actually is.