Business Problem & Solution

A hotel platform sits on the two ingredients of revenue management — live inventory and demand signals — but turning them into the right nightly rate for every room-type and date is a job no operator can do by hand across a thousand properties. Price too low on a high-demand night and you leave money on the table; price too high and the room sells empty. The discipline is real; the bottleneck is doing it consistently, defensibly, and within rules the business can trust.

Dynamic Pricing & Revenue Management reads what the marketplace already holds — occupancy, booking pace, a competitor index, seasonality, weekends and local demand events — and recommends a rate per room-type/date inside an owner-set guardrail band. An owner approves or overrides; the approved rate publishes back onto the shared rate plan the consumer site books against.

It proves the loop is closed end-to-end on the shared data layer: the same inventory the guest books drives the recommendation, and an approved rate ripples back to the listing and out to the channel manager — no private copy of the truth. The 14-day calendar, the per-day driver breakdown, and the guardrail clamping are all live against synthetic data.

It simplifies the model itself, honestly. The recommendation engine is a transparent rule set over a deterministic demand signal — not a black-box forecast — so every number is reproducible and explainable. There is no metered LLM here; the 'demand-forecast' step records a $0 trace labelled deterministic. The launcher tags the app 'AI', but this build is rules-based, and the Architecture doc says exactly that.

Synthetic catalog only — invented properties, rooms, rate plans and demand events. Demand signals are derived deterministically from stable ids (fixed-seed), so a given property/room/date always produces the same recommendation across server render, hydration and tests. Figures are representative and labelled; no real brands, customers, PII, or proprietary pricing logic appear anywhere.