Candy Api Laravel Package

Product Decisions This Supports

• Build vs. buy for Laravel-native plumbing: When a capability is non-differentiating (auth scaffolding, admin panels, media handling, payment plumbing), adopting a maintained package lets the team spend roadmap capacity on product surface area instead of framework glue.
• Framework-alignment on the roadmap: A Laravel/PHP package constrains us to the Laravel ecosystem's conventions, release cadence, and support windows. This informs whether upcoming features are cheaper to ship inside the framework or require a separate service.
• Scope and sequencing: Package capabilities define what can be delivered in a sprint versus what needs custom work — useful when sizing a feature or deciding whether to descope.
• Risk register for dependency decisions: Version 0.21 signals pre-1.0 maturity. That's a signal for how much we lean on it in customer-facing paths versus internal tooling, and whether we need a fallback plan.
• Use-case fit: Best suited to internal tools, admin/back-office workflows, and prototypes; less suited to surfaces where long-term API stability is a hard requirement.

When to Consider This Package

Adopt when:

• We're already on a supported Laravel version and the package tracks current framework releases.
• The problem is well-bounded and the package is a thin, idiomatic layer rather than a parallel abstraction.
• The team can absorb the upgrade cost of a pre-1.0 dependency (expect breaking changes between minor versions).
• It removes meaningful custom code — the win is fewer lines we own and maintain.

Look elsewhere when:

• We need a stability guarantee (semver, LTS) for a customer-facing contract.
• The package duplicates something Laravel already provides, or overlaps a dependency we already carry.
• Community activity, issue responsiveness, or maintainer count is thin relative to how central the capability is.
• The integration would require patching internals or forking — that's a maintenance liability disguised as a shortcut.

Note on this release: The 0.21 notes carry no described changes, so there is no evidence of breaking changes, new features, or deprecations to react to. Treat 0.21 as a version bump pending changelog confirmation before we commit roadmap scope to it.

How to Pitch It (Stakeholders)

For executives: This is a Laravel/PHP library that lets us build standard application functionality on proven, community-maintained code instead of writing it ourselves. The commercial case is velocity: less engineering time on undifferentiated plumbing and more on features customers pay for. The caveat is maturity — it's pre-1.0, so we should keep it out of our most stability-sensitive surfaces until it reaches a stable release.

For engineering: Idiomatic Laravel integration, so onboarding cost is low and it fits our existing conventions. The trade-off is upgrade exposure — pre-1.0 minor releases can break, so we'd want it isolated behind a service boundary and covered by tests at the integration points. Recommend a time-boxed spike to validate fit and measure how much custom code it actually replaces before we adopt it broadly.