Booking Product Laravel Package

Product Decisions This Supports

• Roadmap: opening a time-based revenue line inside the existing storefront. bagisto/booking-product adds a native booking product type to Bagisto, so we can sell services and access — consultations, appointments, classes, tours, equipment or room rentals, event seats — rather than only physical stock. The PM-level value is that this is a new SKU category, not a new business system: no second checkout, no separate order pipeline, no parallel calendar product for support to learn.
• Build vs. buy, framed honestly. The package already ships slot configuration, availability rules, storefront date/time selection, admin-side booking management, and cart/checkout/order integration. That shifts the default from "build a booking engine" (quarters, not sprints) to "pilot this and price the gaps." The correct internal framing is buy a head start, own the risk — 14 stars, 0 dependents, a single tagged release in September 2024. We are adopting a component with no ecosystem safety net, not a vendor.
• Pricing and packaging experiments become catalog work. Per-slot pricing means peak/off-peak, weekday/weekend, and hourly rental tiers can be modelled as product configuration instead of custom promotion code. That lets us run pricing tests — premium slots, deposits on high-demand times — without an engineering ticket per experiment. Caveat worth validating early: per-slot price overrides often bypass tier pricing, cart price rules, tax classes, and multi-currency formatting, so finance needs one reconciliation test before we promise anyone a pricing lever.
• Capacity and overbooking policy moves from an engineering default to a PM decision. For booking products, quantity per slot is the overbooking policy — and v1.1.0 reworked the "Product Quantity System" with no detail in the release notes. Before launch we must state and publish: how many bookings a slot may take, whether capacity is per slot or per product per day, and what the customer sees at sell-out. This is a business rule currently hiding inside a minor release note; it should not be settled by whoever happens to read the code.
• Cancellation and refund policy design. The package models booking creation. Whether cancellation releases capacity back to inventory is something we must specify and verify as an acceptance criterion, not assume. If it doesn't, availability decays permanently and we quietly stop selling slots we still hold — a revenue leak that surfaces weeks after launch and is very hard to attribute to its cause.
• Operational ownership (who is on the hook). Admin booking management means operations staff — not engineers — confirm, reschedule, and cancel. That implies a runbook, training, and an explicit answer to "when a customer's slot is wrong, who fixes it?" Decide early whether this sits with ops or support; it changes headcount assumptions and SLA language.
• Platform commitment, as a negative decision. This package is only a candidate if Bagisto is already our platform. If we're not on Bagisto, the real question is "should we adopt Bagisto," and a 14-star, zero-dependent extension is evidence against that move, not a reason to make it.
• Fork threshold as a planning artifact. Requirements likely to exceed the package: recurring/subscription bookings, multi-resource allocation (several rooms or staff per booking), deposits and no-show fees tied to cancellation windows, and two-way calendar sync. We should name the line in advance so crossing it is a scheduled roadmap conversation ("fork or move to a managed booking engine") rather than a mid-sprint discovery.

When to Consider This Package

Consider it when:

• We are already running Bagisto and booking is a new product type inside the existing catalog — not a standalone scheduling business with its own front door.
• The commercial model is simple and time-boxed: fixed slots, availability windows, per-slot price, per-slot capacity. Appointments, classes, tours, table/seat reservations, short-term rentals, equipment hire.
• We want the booking flow to live inside the existing cart, checkout, tax, currency, and order-admin experience — so customers, finance, and support see one order record, not two.
• The volume profile is modest and predictable (hundreds to low thousands of bookings per month). Above that, the availability lookup becomes a hot path and we need evidence it scales with booking history, not just product count.
• We can staff a named owner on the engineering side for the integration, upgrades, and the concurrency and cancellation tests — because there is no upstream community catching regressions for us.

Look elsewhere when:

• We are not on Bagisto. Then this is a platform decision, not a package decision.
• Booking is calendar-centric rather than catalog-centric — staff scheduling, resource allocation across multiple people or rooms, real-time two-way Google/Outlook sync, waitlists. That's a managed booking engine, not a product type.
• We need deposits, no-show fees, or cancellation-window pricing as first-class behaviour. These typically require custom work here and belong in the fork-threshold conversation.
• Sub-slot concurrency matters commercially — a last-seat-on-a-flight, high-contention scenario where double-booking is unacceptable at any rate. Verify the package uses a unique constraint or lock rather than check-then-insert before committing; if it doesn't, treat it as build-or-fork.
• The storefront requires heavy calendar UX customisation — published Blade overrides diverge permanently and turn every package bump into a manual three-way merge.

How to Pitch It (Stakeholders)

To executives — one paragraph: We can add a bookable product type to the store we already run — appointments, classes, rentals, reservations — without building a booking engine or standing up a second checkout. It's a low-cost way to test a time-based revenue line in weeks rather than quarters. The trade-off is explicit: this is a small, single-maintainer package with no adoption to speak of, so we take on the integration testing and upgrade discipline ourselves. Approve it as a time-boxed pilot with a named success metric and a kill criterion, not as a platform commitment.

To engineering — the honest brief: Treat this as source-code-as-specification. Read the service provider, the migrations (especially indexes on slot/availability lookups), the models' datetime casts, and the storefront availability endpoint before wiring anything. Two things are non-negotiable acceptance tests: (1) a full lifecycle test — book → order item carries slot data → cancel → capacity restored; (2) a concurrency test — N parallel checkouts on the last available slot, exactly one succeeds, run against the production DB engine. Assume double-booking risk until disproven by a unique index, pessimistic lock, or atomic decrement. Never upgrade Bagisto core and this package in the same release; with zero dependents, we are the integration test suite. The v1.1.0 quantity-system change is our highest upgrade risk — the diff is the changelog, so write our own upgrade note.

To operations and support — what changes for them: Booking confirmations, reschedules, and cancellations happen in the existing admin, alongside normal orders. They need a runbook, a trained owner, and a clear escalation path. Two policies must be finalised before launch because they define the customer promise: how many bookings a slot can hold, and what happens to the slot when someone cancels.

The three things to decide before we commit a sprint: capacity/overbooking policy per slot, cancellation-releases-capacity as a verified behaviour, and the fork threshold (recurring bookings, multi-resource allocation, deposits/no-show fees, calendar sync). Naming those now turns future escalation into a planned roadmap conversation instead of a mid-sprint surprise.