One Booking Platform, Different Venue Rules

01 / 06

The request sounded like a UI change

A pilot venue had a clearer booking grid and checkout summary. Bringing that presentation to another venue sounded like component reuse. The risk was that the pilot also had different booking increments, a longer reservation window and a multi-room cart. Copying the experience wholesale could import those business assumptions.

I treated presentation and policy as separate choices. The target venue could use the new grid without adopting the pilot’s 15-minute steps, customer-selected membership minutes, rental-club add-ons or four-week window. Those were local requirements, not implicit upgrades for every customer.

02 / 06

Make capability selection explicit

The implementation introduced a venue booking configuration registry. It selected the presentation capabilities and referenced the appropriate rules for that venue. Unregistered venues retained the existing guided interface. A new entry extended the platform without editing a global default.

The target venue kept 30-minute start and grid increments, durations of 30, 60, 90 or 120 minutes, a two-hour maximum, a 14-day window and one bay per booking. Membership benefits remained automatically calculated. Server-authoritative quoting and the established checkout path also stayed in place.

03 / 06

Reuse the interaction, not the desktop geometry

The desktop experience used rooms across the grid and times down the page, with a persistent booking summary. On a phone, shrinking that table would have made the choices harder to scan and tap. The mobile view instead grouped bay cards by time.

The date selector exposed the full 14-day window through seven-day pages. Changing the day retained the existing client cache and prefetch behavior. A visible redesign was not a reason to discard the performance work already supporting date navigation.

04 / 06

Test the non-change as part of the change

The booking-rule checks gained venue-isolation assertions: the target venue could change presentation without changing its business rules. I also checked the page against a temporary database, including the reservation window, pagination, desktop grid and phone layout. That work did not write to an operating venue’s data.

The important negative checks are product-specific. Enabling a grid must not enable a multi-bay purchase. Reusing a summary must not let the customer choose membership minutes if the venue calculates them automatically. Those constraints belong in the integration boundary, where configuration becomes behavior.

05 / 06

Keep a failing baseline visible

The record reports type checks, lint, build and public-copy checks passing. The broader acceptance run completed the booking, pricing, waiver, reservation-window and relevant coaching checks before stopping at an existing OAuth test-account login failure. It reproduced on the second run.

I kept that as a separate baseline issue rather than claiming the whole suite passed or changing the authentication system to make a UI task look green. This article describes the implementation and the recorded local verification. It does not turn the temporary-database check into evidence of a production rollout.

06 / 06

Local requirements should remain local

A configurable platform is easier to extend when it is explicit about what is shared: rendering primitives, interaction patterns and tested rule interfaces. Prices, time windows and commercial permissions are inputs to those interfaces. Keeping that distinction visible let me improve a customer flow without redefining another venue’s contract.