Hotel Card Delivery Bundle Laravel Package

Product Decisions This Supports

• Feature viability for card/voucher delivery: the package targets the fulfillment step of hotel card products (voucher/coupon issuance and hand-off to a delivery channel). Useful as a scoping reference when deciding whether post-booking perks, digital gift cards, room-key/access-card hand-off, or partner voucher distribution are worth building.
• Build vs. buy on fulfillment plumbing: it lets you compare "compose an existing card-delivery abstraction" against "write our own issuance + delivery adapters." At 0.0.1 it is a build-vs-buy data point, not a decision-maker.
• Roadmap sequencing input: if hotel-card perks sit in a later quarter, this can be evaluated cheaply now and revisited once the package stabilizes past 0.x.
• Architecture signal: the *-bundle naming and tourze ecosystem conventions hint at a Symfony-style bundle rather than a Laravel-native package. That matters for whether it fits our service providers, config publishing, and DI patterns — decide integration approach before committing roadmap dates.
• Explicit non-decision: at 0.0.1, with no documentation, no stated API surface, and release notes containing only a changelog link, this should not anchor a committed roadmap item. Treat it as a disposable spike input.

When to Consider This Package

Consider it when:

• We are prototyping a card/voucher issuance-and-delivery flow and want a reference domain model rather than a bespoke one.
• The app already lives in, or interoperates with, the tourze PHP ecosystem, so conventions and dependencies are shared.
• The need is generic "issue a card, deliver it to a guest" plumbing and we can wrap it behind our own interface.

Look elsewhere when:

• We need production guarantees: versioning policy, changelog depth, tests, security posture. 0.0.1 with a link-only changelog provides none of these signals.
• We require Laravel-native integration (auto-discovered service providers, publishable config, Eloquent models). A "bundle"-style package may need custom wiring, which erodes the buy-side savings.
• A single well-supported vendor already covers the flow — e.g. payment-rail card issuing, or a hosted voucher/loyalty platform — since owning delivery logic adds maintenance surface for little differentiation.
• Our card semantics are highly proprietary (pricing rules, entitlements tied to PMS/CRS data); a generic bundle will be more wrapper than leverage.

Adoption criteria before promoting beyond a spike: documented public API, supported PHP/Laravel versions, at least a stable 0.x with meaningful release notes, and a tagged issue/maintenance cadence.

How to Pitch It (Stakeholders)

Executives: There is a small, very early-stage PHP package that could shortcut the plumbing for hotel card and voucher delivery — issuing a card and getting it to the guest. The upside is time-to-market on loyalty perks and gifting; the cost to evaluate is a few engineering days. It is not production-ready: version 0.0.1, no documentation, and release notes that only link to a commit list. Recommendation: fund a timeboxed spike, no roadmap commitment until it matures or we confirm our own wrapper insulates us.

Engineering: Assess the public API surface, supported PHP/Laravel versions, test coverage, and dependency footprint. The *-bundle convention suggests Symfony heritage — verify how it registers in a Laravel app and whether it can be isolated behind an internal interface so we are not coupled to a 0.0.1 package. Confirm license and maintenance cadence before any code lands on a shared branch.

Risk framing: low downside (cheap to trial, easy to discard), low current maturity. The decision to make now is only "spike or defer," not "adopt."