Statamic Api Select Laravel Package

Product Decisions This Supports

• Build vs. buy for the addon's capability area. A 1.0.0 "initial launch" is the vendor's first public stability commitment. It gives you a defensible moment to ask: does this replace work we'd otherwise fund on our roadmap, and is the scope close enough to our requirements to avoid heavy customization?
• Roadmap sequencing and de-risking. Because the package just crossed into 1.0.0, there is no track record of upgrades, deprecations, or response to ecosystem changes (Laravel major versions, PHP minor releases). Treat adoption as a time-boxed spike, not a committed roadmap dependency, until you have your own evidence.
• Feature scoping and gap analysis. The release notes carry no feature detail beyond "initial launch," so the decision input is the package's documented capability surface — not its changelog. Expect to map its surface against your acceptance criteria manually before any commitment.
• Pilot vs. platform-wide rollout. A first stable release is a reasonable candidate for a single low-blast-radius service or internal tool. It is not yet evidence for a platform-wide standard, and the decision to standardize should be a separate, later call.
• Vendor and maintenance-risk posture. A 1.0.0 with no prior public history means support responsiveness, security disclosure process, and long-term maintainer commitment are all unproven. This informs whether you accept the dependency or wrap it behind an internal abstraction.

When to Consider This Package

Adopt it for evaluation when:

• The package's documented scope overlaps with a capability you would otherwise build, and the overlap covers the majority of your must-haves rather than the edges.
• You can absorb the dependency behind a thin internal boundary (interface, adapter, or service wrapper) so a later swap or removal is a contained change.
• Your team is on a Laravel/PHP version the package explicitly declares support for, and you can pin the version rather than float it.
• You have a low-risk surface — internal tooling, a non-customer-facing service, a prototype — where a first-release package cannot damage revenue or customer trust.
• Someone owns the evaluation: a named engineer to run the spike and a review date to decide keep or drop.

Look elsewhere when:

• The capability is on your critical path or in a regulated, audited, or customer-facing flow where an unproven dependency is an unacceptable risk.
• The package would be a hard dependency of your core domain model rather than an edge concern, making eventual removal expensive.
• The package's declared support matrix lags your Laravel or PHP version, or its scope only partially matches and would require forking to be useful.
• You need a published security policy, a maintenance SLA, or a migration/deprecation history before you can sign off — none of which a 1.0.0 initial launch can demonstrate.
• The work is small enough that building a narrow internal implementation is cheaper than the integration, review, and ongoing dependency-tracking cost.

How to Pitch It (Stakeholders)

To executives: A Laravel addon just reached its first stable release (1.0.0). That is the earliest point at which a dependency like this becomes reasonable to evaluate, because the maintainer is now signalling API stability. I am not recommending adoption yet — I am recommending a bounded, time-boxed evaluation on a low-risk surface, with a decision date. The cost is a small amount of engineering time; the upside is either removing planned build work from the roadmap or confirming we should build it ourselves. The risk we are managing is a dependency with no upgrade history, and the mitigation is keeping it behind an internal boundary so removal stays cheap.

To engineering: This is a 1.0.0 initial launch, so treat the API as promised-but-unproven. Please (1) confirm declared support for our Laravel and PHP versions, (2) verify the capability surface against our requirements rather than assuming the changelog describes it, and (3) integrate it behind an adapter so we are not coupled to its public API. Report back on code quality, test coverage, and how it behaves on a version bump before we consider anything beyond a pilot.