An imagined house. A working experience.
A flagship hospitality portfolio concept: twelve rooms, considered design, and a complete booking journey that lives in your browser.
Portfolio demonstration. Reservations are saved in this browser only. No payment is taken and no room is reserved.
Preparing this browser’s sample house…
What to try.
- Find a room. Try sample dates, compare rooms, change guests, and open the nightly price breakdown.
- Make a demo stay. Choose extras, use a fictional sample guest, and review. In the demo payment control, decline preserves the draft; success saves a reservation and message together.
- Make it yours. Print the confirmation, download an all-day calendar file, amend a future stay after seeing the difference, or cancel for a simulated refund.
- Step behind the desk. Find the same record in Reservations. Inspect unit availability, add non-conflicting maintenance, change a local base rate, and preview the local message.
- Leave a note. Save a Contact, Dining or Experience inquiry; it appears in the dashboard. Reset the sample house when you want to start again.
A few intentional boundaries.
Same-origin tabs in the same browser profile share localStorage. Separate devices, browsers, origins and private contexts have separate state. Clearing site data removes the records. A booking reference opened elsewhere explains why it is missing.
Browser storage is user-editable. It is not secure authentication or authorization, and it cannot guarantee atomic inventory across tabs. The front desk is openly accessible. There is no live shared reservation system.
Use fictional details. There are no passwords, card details, identity documents, analytics, outbound messages, backend services or database. If storage is disabled, full or corrupt, browsing stays available and saving requires an explicit temporary-session fallback. Temporary data disappears on reload.