Case study · Booking simulation

03 — 04

AulaBeach

Choosing a spot is a spatial question, not a list question.

A Laravel application for finding a beach club and simulating a booking. Search, availability by date and time slot, a plan of the actual beach, confirmation and cancellation — with the sun moving across it.

Role
Full Stack Web Developer
Status
Booking simulation
Stack
Laravel · Livewire · Alpine.js · Tailwind CSS · MySQL
Source
Private repository

01 · Context

A spot is not a stock item.

A beach club does not sell thirty-six identical units. Availability depends on the date, the time slot, and where the place physically is. The search has to carry all three before a map is worth showing.

The capture is the running application, unmodified.

Product capture
AulaBeach search results with preference controls, filters, and three beach clubs with pricing and ratings.
Search contextPreferences drive the map3 clubs · from €22

02 · Direction

How do you want to spend the day?

AulaMatch does not ask for a rating. It asks what you want from the day, then scores every place against it. Here, those five preferences directly shape the plan below.

1 preference now driving the plan below ↓

Product capture The same five preferences, in the application
The AulaMatch preference panel in the running AulaBeach application.

03 · Feature focus

The plan

Seen from above: the sea at the top, the boardwalk in the middle, the services at the bottom.

Interactive model

Time slot

Midday · full sun

A4 m

B12 m

C20 m

D28 m

E36 m

F44 m

36 places · 11 taken

04 · Experience

Three steps and a code.

The booking never leaves the same frame. Place, details, confirmation — and cancellation stays available until the day before. No real payment is ever taken, and the product says so on every screen.

Personal-looking demo data in the second capture is masked.

Product capture Model pick: — · capture recorded on A3
Step one: the station map with date, guests, time slot, and AulaMatch suggestions. Step two: masked name, email and phone fields with demonstration booking conditions. Step three: booking confirmation with a demonstration code and cancellation option.
01 Place · choose on the map Demonstration booking · no real payment

05 · Responsive

The plan stays a plan.

The 6×6 grid is not collapsed into a list on a phone. It keeps its geometry and gains a persistent bar carrying the selected place, so the map never has to give up the one thing it is for.

Product capture

Captured at 402 × 869. Three steps of the same journey.

AulaBeach on a phone: destination, date, guests, and the search action.
01Search · date and guests
AulaBeach on a phone: beach club details, services, availability, and a pinned action.
02Club · action pinned
AulaBeach on a phone: the full six by six station map and selected-place bar.
03Plan · selection pinned

06 · What holds it up

A simulation, declared.

Availability, scoring and reservation stay separate, so the preferences and time used by AulaMatch never decide whether a place is actually available. One request crosses five responsibilities, in this order.

  1. 01 · Entry

    Laravel

    Routing, validation and the demonstration guard on every write.

  2. 02 · State

    Livewire

    Holds date, guests, time slot and the selected place without a page reload.

  3. 03 · Advice

    AulaMatchService

    Scores every free place with deterministic, explainable rules.

  4. 04 · Truth

    Availability

    Date and station status. The only concern allowed to say no.

  5. 05 · Outcome

    Reservation

    Issues the code and keeps eligible cancellation open until the day before.

Repository
Private. Code available on request.
What is real
Every capture comes from the running application; only personal-looking demo fields are masked. Distances, prices, states and scoring rules match the source.
What is reconstructed
The editorial plan, moving sun, tilt and the fixed 11-position occupancy snapshot are built for this case study and do not write product data.
Next project · 04 Virginia