Nova Blockchain Exchange Rates Laravel Package

Product Decisions This Supports

• Build vs. buy (or build vs. adopt): A stable v1.0.0 is the first release where the package is committing to semantic versioning. That is the moment a "wrap our own" or "copy a snippet from a blog post" decision can be honestly compared against a maintained dependency — the maintenance cost of in-house code is now measurable against a versioned, upgradeable alternative.
• Platform standardization: Whether to make this capability a default in the Laravel service template / starter kit for new products, versus leaving it to individual teams. A 1.0 boundary is the earliest point where a platform team can standardize without signing up for constant breaking-change firefighting.
• Roadmap sequencing: Adoption cost lands in the current sprint, but the payoff is deferred (fewer bespoke implementations, faster onboarding). This informs whether it goes in "now," "next," or "later," and whether it needs a spike before it can be committed to a delivery date.
• Retrofit vs. greenfield: Greenfield services can adopt at near-zero cost; existing services need a migration and backfill story. That asymmetry usually argues for "new services only" in the first release cycle.
• Risk posture on third-party dependencies: Introducing a new dependency expands the supply-chain and upgrade surface. For a 1.0 release, the question is not "is it mature?" (it isn't, yet) but "is the blast radius contained if it stalls?"
• Use cases worth validating in discovery: the concrete jobs the package replaces — the manual/boilerplate workaround teams use today — so the adoption case is measured in removed toil, not in abstract elegance.

When to Consider This Package

Consider it when:

• Stack alignment is verified, not assumed. Confirm supported Laravel and PHP versions against the versions actually running in production, including the oldest service you'd want to adopt it in. The Laravel ecosystem moves fast; a package that only supports the last two majors silently excludes part of the estate.
• The problem is recurring, not one-off. It pays off where the same capability would otherwise be rebuilt two or three times across teams.
• There is an escape hatch. You can wrap it behind your own thin interface, so replacing it later is a contained change rather than a rewrite.
• Maintenance signals are legible. Clear release history, tests in CI, an issue tracker that gets answered, a license compatible with commercial use, and a maintainer with a track record. v1.0.0 is a starting point to judge these, not proof of them.
• The dependency footprint is proportionate. Check the transitive dependency tree before adding it to a service with a strict security or audit posture.

Look elsewhere when:

• The package is the only thing standing between you and a hard framework upgrade — no compatibility path means you inherit its release cadence.
• It reaches into areas you'd need to own long-term (money, auth, PII handling) without a credible bus-factor or a fork-and-maintain plan.
• Adoption requires patching internals or depending on undocumented behavior. That is a signal the abstraction is wrong for your use case, not a small integration detail.
• A first-party framework feature already covers most of the need; two dependencies doing overlapping jobs is a tax you pay on every upgrade.
• The team cannot articulate who owns the upgrade when the next major lands.

How to Pitch It (Stakeholders)

For executives: This is a small, contained bet on a versioned open-source component rather than bespoke code. The immediate win is time-to-market on the specific capability — we avoid rebuilding something we'd otherwise write, test, and maintain ourselves. The risk is deliberately bounded: it sits behind our own interface, its 1.0 release means the maintainers have committed to a stable API, and if it stalls we can replace it without touching product surface area. The decision I'm asking for is approval to adopt it in new work first, with a review before any wider rollout.

For engineering: Version 1.0.0 is the first release with a semantic-versioning promise, so upgrade cost becomes predictable from here. Integration is deliberately thin — we wrap it rather than call it directly — so the dependency stays swappable. What I need from you before we commit: confirmation of version support against our oldest production service, a read on the dependency tree, and a named owner for upgrade cadence. If those three come back clean, the ask is a timeboxed pilot in one new service, with a go/no-go before it enters the service template.