Booking Product Laravel Package

Technical Evaluation

Architecture fit. This is a Bagisto module, not a standalone library — it extends the platform by registering a new booking product type alongside existing types, so merchants sell time-based inventory through the same catalog, cart, checkout, tax, currency, and order-admin surfaces as physical goods. From a TPM standpoint that is the whole value proposition: a new SKU category, not a new business system. No second checkout, no parallel order pipeline, no separate calendar product to staff and support. If Bagisto is already our platform, fit is high and the integration surface is narrow and well-bounded. If Bagisto is not already our platform, this package is not a reason to adopt it — a 14-star, zero-dependent extension is evidence against that move, not for it. That is the first decision gate, and it should be answered before any engineering time is spent.

Integration feasibility. Installation is conventional for a Laravel package: composer require, optimize:clear, migrate, vendor:publish, storage:link. There is no data migration for existing SKUs — booking is additive. Feasibility is confirmed by three observable signals rather than by reading code: the product type appears in Admin → Catalog → Products → Create → Type, the booking admin screens render, and the storefront shows a calendar/date-time selector on a product of that type. If any of those three is missing, stop and fix it before scoping anything. The real extension map lives in the package's service provider (config merges, routes, views, event bindings, product-type registration) — that single file tells us where our customization budget will go.

Technical risk. Ranked by business severity, not by likelihood:

1. Double-booking. This is the highest-severity defect in any small booking package and the most likely to be present. If availability is check-then-insert rather than a unique index, pessimistic lock, or atomic decrement, two simultaneous checkouts both succeed and no amount of sequential testing reveals it. This must be personally disproven with a parallel-request test against the production database engine — SQLite will lie about locking. This is a launch blocker, not a backlog item.
2. Cancellation capacity release. The package models booking creation. If cancellation does not return capacity to inventory, availability decays permanently and we silently stop selling slots we still own — a revenue leak that surfaces weeks post-launch and is very hard to attribute. Verify on the first lifecycle walkthrough and again after every upgrade.
3. The v1.1.0 "product quantity system" change. For booking products, quantity per slot is the overbooking policy. The release note says "improved" and does not say what changed. The diff is the changelog; we must write our own internal upgrade note covering schema changes needing backfill and any change to the decrement/locking strategy.
4. Timezone and DST. Determine whether slots are stored in UTC or store timezone and whether there is a per-product override. Test a DST transition day in a non-UTC store timezone. Off-by-one-hour bugs here are common, customer-visible, and hard to reproduce after the fact.
5. Per-slot pricing vs. the discount/tax engine. Per-slot price overrides frequently bypass tier pricing, cart price rules, tax classes, and multi-currency formatting. Test a booked slot with an active cart discount and a non-base currency. Decide up front whether services need a separate tax class from goods.
6. Ecosystem risk. One maintainer, one tagged release (2024-09-16), 14 stars, 0 dependents. We are adopting a component, not a vendor. We are the integration test suite — there is no ecosystem catching regressions for us.

Key questions to answer before committing engineering time.

• Is Bagisto already our platform, or is this a proxy for a platform decision?
• Is the launch scope genuinely simple — fixed slots, availability windows, per-slot price, per-slot capacity — or does the roadmap already imply recurring bookings, multi-resource allocation, deposits/no-show fees, or calendar sync?
• Who owns booking operations (confirm, reschedule, cancel) — ops or support — and what is the SLA when a customer's slot is wrong?
• What is our stated overbooking policy, published as a business rule rather than settled by whoever reads the code?
• Does cancellation release capacity, and if not, do we accept a reconciliation job as launch scope?
• Where is the fork threshold, named in advance?

Integration Approach

Stack fit. Bagisto + PHP + MySQL. The only meaningful constraint is the Bagisto core we already run. Before touching Composer, record three facts in the PR description: exact bagisto/bagisto version, PHP version, and DB engine. If those don't match the package's composer.json, stop — a version mismatch is a hard blocker, not a nuisance. MySQL is assumed; if we run Postgres, locking and DATETIME semantics differ and the concurrency test becomes even more important.

Migration path. Greenfield for booking data: existing products, orders, and customers are untouched. Two things still need a plan. First, if we are replacing an incumbent booking tool (Calendly, a spreadsheet, a legacy scheduler), there is no import path in this package — that migration is manual or scripted by us and belongs in the estimate. Second, admin assets: Bagisto's admin is Vue-based and published assets must match the installed Bagisto build, not a nominal version. A mismatch presents as blank admin screens or console errors, not a PHP exception — so check the browser console before the Laravel log when scoping.

Compatibility discipline. Pin the core version, pin the package tag, and never bump both in the same release. One variable at a time: core first, verify the lifecycle, then the package tag, verify again. Define the fork threshold in advance — recurring/subscription bookings, multi-resource allocation, deposits and no-show fees tied to cancellation windows, two-way calendar sync. Crossing that line is a scheduled roadmap conversation about forking or moving to a managed booking engine, not a mid-sprint patch.

Sequencing. Run this as a time-boxed spike with explicit exit criteria, not a feature sprint.

1. Install and verify the three signals on staging.
2. One product, capacity 1. A single 30-minute consultation with a fixed weekly window. Walk browse → slot → cart → checkout → order → admin booking → cancel → slot available again, snapshotting table rows at each step. That trace is our regression baseline and the evidence for whether cancellation releases capacity.
3. Concurrency test. N parallel checkouts against the last available slot; exactly one must succeed. Launch gate.
4. Commercial-correctness test. Per-slot price with an active cart discount, a non-base currency, and a service tax class.
5. Operations handover. Runbook, training, and the answer to "who fixes a wrong slot?"
6. One-product pilot, then widen the catalog.

Override views last and only for cosmetics — published Blade overrides diverge permanently and turn every bump into a manual three-way merge. Precedence: config → event/listener → view override → class override/fork. Attach booking metadata through the package's existing cart-item pipeline, never around it, or admin screens and refunds lose context.

Operational Impact

Maintenance. The real cost is upgrade labor, and it is ours. With no dependents and a single maintainer, every Bagisto core bump and every package tag is a manual verification exercise against our lifecycle baseline. Budget it as recurring, not one-time. Publish an internal upgrade note per tag based on the actual diff — the release notes are marketing, the diff is the changelog.

Support. Booking admin means operations staff, not engineers, confirm, reschedule, and cancel. That implies a runbook, training, and a headcount/SLA decision made early. Support-facing failure modes are rarely PHP exceptions — they are "the slot shows unavailable," "the booking vanished," and "the total is wrong." The support rule is: query the booking and slot tables directly; the UI is a projection, the tables are truth. Keep query logging or Telescope on in staging so the availability query and its bindings are inspectable.

Scaling. The storefront availability endpoint is the highest-traffic, highest-risk route — it is hit on product views and re-validated at cart and checkout. Read the migrations for indexes on slot/availability lookup columns before running them; that is the cheapest point to spot a scaling cliff. Instrument the availability path in week one with realistic booking history: if lookup degrades non-linearly with booking count, we want to know then, not at month three. The realistic volume profile for this package is modest — hundreds to low thousands of bookings — and that should be stated as an assumption, not discovered as a ceiling.

Failure modes to plan for.

• Double-booking under load — the launch-blocking one; mitigated by the concurrency gate.
• Silent capacity decay from cancellation — mitigated by the lifecycle test and, if needed, a scheduled reconciliation job before launch rather than after.
• DST off-by-one — mitigated by the transition-day test on a non-UTC timezone.
• Blank admin screens — asset/build mismatch; check the browser console first.
• Orphaned bookings from schedule edits — changing slot duration, windows, or capacity on a live product reinterprets existing bookings, and there is usually no configuration versioning. Policy: never edit a live booking product's schedule once it has bookings — clone the product instead.
• Discount/tax miscalculation on per-slot prices — mitigated by the commercial-correctness test, with a separate service tax class decided up front.

Ramp-up. Assume two to three weeks of engineering to reach a trustworthy one-product pilot: install and verify, lifecycle baseline, concurrency proof, pricing/tax proof, and a fixture seeder so "slot is taken" states are reproducible without manual clicking. Add operations training and the runbook before the first customer sees a calendar. The PM-level framing to carry into the review is buy a head start, own the risk — this package replaces quarters of booking-engine build with a configurable product type, provided we budget the verification and upgrade overhead as ongoing, and name the fork threshold before a sprint discovers it for us.