roomMaster Web App — DAU +700% on US launch day
Vibe-coded a modern web app on top of a 40-year-old Clarion PMS for 1,500 hotels. The single API surface I built unblocked seven downstream products — and the Housekeeping PWA I shipped solo proved the contract end-to-end before anyone else integrated.
- DAU on US launch day
- +700%
- Hotels migrated
- 1,500+
- Products unblocked
- 7
- Uptime target
- 99.9%
Problem
roomMaster Cloud was a 40-year-old Clarion PMS running on Windows desktops over RDP across 1,500 hotels in APAC, UK, and the US. No mobile interface, no SSO, no centralized file storage, no clean API surface. Customers were stuck on a desktop client built for a decade that no longer existed.
The rest of the Valsoft hospitality portfolio — Booking Engine, Channel Management, AI Concierge, AI Revenue Management, AI Voice Agent, Metasearch — had no clean way to integrate. Each satellite team that wanted to plug into the legacy PMS had to navigate the same undocumented Clarion codebase and denormalized MariaDB schema independently.
The strategic answer was roomMaster Nova (cloud-native rebuild via AI PDLC). But Nova was a long-term effort by a four-person team and would not be customer-ready for months. In parallel, the legacy rw5main product itself is being ported screen-by-screen via an audit-first parity pipeline — this web app is the third leg: the interim layer that ships modern functionality on top of the untouched legacy today.
Approach
I designed and vibe-coded the roomMaster Web App as an interim modernization layer on top of legacy roomMaster Cloud — sharing the same Next.js + NestJS + MariaDB + Redis stack later adopted by Nova. It served two purposes simultaneously: existing customers got the modern functionality they were asking for, and every satellite product team got a single API surface to integrate against without ever touching Clarion.
- Single API surface, derived from the legacy.
Built one stable HTTP/REST surface that wrapped the Clarion business logic. Every satellite product (Booking Engine, Channel Management, AI Concierge, AI RMS, AI Voice Agent, Metasearch) integrates against this contract — not the underlying Clarion. Owning the contract myself meant I could move it deliberately as the satellites' needs evolved.
- Database-per-tenant isolation, enforced at the request boundary.
Multi-tenant DB-per-tenant model with a TenantGuard middleware running on every API request. Complete data isolation between properties at 1,500-hotel scale, with no cross-tenant query path even theoretically possible.
- PCI-compliant payments via Adyen tokenization.
190+ payment methods globally, no cardholder data stored locally. The PCI scope sits with Adyen; we handle tokens. This is the kind of decision that’s expensive to retrofit — got it right at the schema level on day one.
- Real-time dashboard via Server-Sent Events.
Occupancy, revenue, arrivals, departures, housekeeping status — pushed to clients within 500ms of database changes. Avoided the WebSocket complexity tax by using SSE for the unidirectional reality of dashboards.
- Vibe-coded with Cursor + Claude.
Prototyped, iterated, and shipped using AI-assisted development. The same toolchain pattern that the AI PDLC formalized later — proven first on this product at 1,500-hotel scale.
The web app is the connective tissue between a legacy system that couldn’t be touched, a long-term rebuild that couldn’t ship in time, and an entire portfolio that needed to ship on a quarterly cadence regardless.
What shipped
- Single API surface, region-rolled APAC → UK → US.
The contract every satellite product integrates against. Same release runbook applied region-by-region; each cutover produced directly comparable rollout data.
- FileStorage.
Property documents, IDs, and operational artifacts unified across the portfolio. Per-tenant scoped, deduplicated at the storage layer.
- SSO for hotel staff.
Replaced per-machine local accounts. Single sign-on across the modern web app and the satellite ecosystem.
- Integration APIs.
The single contract that AI Concierge, Booking Engine, Channel Management, AI RMS, AI Voice Agent, and Metasearch all consume. No satellite team re-did the legacy archaeology.
- PCI-compliant payments (Adyen).
190+ payment methods, tokenized end-to-end, no cardholder data stored locally.
- Real-time dashboard (SSE).
Occupancy, revenue, arrivals, departures, housekeeping status — sub-500ms latency from DB to screen.
What the API contract unblocked
The point of the single API surface was leverage: each product below integrated against the contract instead of re-doing the Clarion archaeology, and shipped on its own cadence. Their launch results are the payback on the platform investment.
- Booking Engine.
+35% conversion, +15% booking value, +60% mobile share.
- Channel Management.
99.95% uptime across the launch quarter.
- AI Concierge.
+35% bookings, +60% CSAT, −35% operational cost.
- AI Support Agent.
Multichannel (chat / voice / email), two-stage agent with a 5-layer safety pipeline. Architecture deep-dive on the AI PDLC page.
- AI Revenue Management (Ampliphi).
+35% RevPAR, +40% ADR, 29 hours/month saved per property — deep-dive below.
- Plus.
Housekeeping mobile app, Admin Portal, and Metasearch integrations.
None of these shipped on this timeline without the contract underneath them — same instrumentation, same release runbook, same SLO scaffolding, inherited from the platform rather than re-invented per team.
Housekeeping — the API canary
Housekeeping — desktop dashboard and PWA on mobile, sharing the same API surface every satellite product later consumed. Click either to enlarge.
To pressure-test the API contract before scaling it across all satellite teams, I built the Housekeeping experience first — desktop and a companion PWA sharing the same endpoints the rest of the platform would consume. If the API broke for housekeeping (the highest-frequency, lowest-tolerance workflow on property), it would break for everyone. Building it myself meant I felt every round-trip cost and every response-shape mistake before they showed up in someone else’s sprint. The PWA caught two API-contract regressions in pre-prod that would otherwise have surfaced as P1s in week two of the rollout. Auto-assignment algorithms and real-time task tracking on top of that contract replaced paper-based workflows at hundreds of properties.
System enabled by the platform: Ampliphi
The clearest proof that the rm-web-app API contract was the right shape: Ampliphi, the native AI revenue-management module, shipped as a downstream consumer with zero legacy archaeology. Independent hotels and small chains running roomMaster Cloud previously had no integrated RMS — pricing was experience, spreadsheets, and gut. Enterprise platforms (IDeaS, Duetto, Revinate) existed but were priced for large chains, required lengthy onboarding, and operated as external systems that never fully integrated with the PMS. Ampliphi could fill that gap because the rm-web-app data layer made it possible.
- Multi-source data layer.
Historical booking data (pace, lead time, cancellations, length of stay), real-time roomMaster operational data (availability, occupancy, RevPAR/ADR by channel), external market signals (events, competitor rate feeds via SiteMinder), seasonal/calendar context — all queryable through the rm-web-app API contract.
- Forecasting + pricing model.
Demand forecasts and rate recommendations per room type, calibrated against the property’s own history. The model improves with each property’s booking data.
- Native recommendation surface.
Recommendations land inside the roomMaster Revenue Management module — same workflow managers already use, no new app, no SSO, no separate vendor.
- Bounded auto-pilot.
Managers set rules to auto-apply recommendations within configured bounds — full manual control where needed, light-touch automation everywhere else.
The technical debt that would have made AI-powered revenue management impossible on the legacy stack had been eliminated before Ampliphi was built. The data model normalization, the structured warehouse, and the single API surface — those are what shipped here, and Ampliphi’s outcomes are how they paid back.
Outcome
Web app · Launch day
DAU +700%
Largest single-day usage spike in the product line. Customers who had been waiting on cloud parity moved within 24 hours of US launch.
Web app · Coverage
1,500+ hotels
APAC, UK, US live at 99.9% uptime. Every property migrated from Windows-desktop roomMaster Cloud to the web app as their interim home while Nova is being built.
Web app · Platform leverage
7 products unblocked
Booking Engine, Channel Management, AI Concierge, AI RMS, AI Voice Agent, Metasearch, Housekeeping — all consume the single API surface. None ship on this timeline without it.
Ampliphi · Top-line lift
+35% RevPAR
Driven by dynamic rate optimization during high-demand periods and demand stimulation during low ones — measurable shift, not marketing claim.
Ampliphi · Rate
+40% ADR
Average daily rate moved meaningfully because recommendations could push prices up during demand spikes that static workflows couldn’t see in time.
Ampliphi · Operator time
29 hr / mo saved
Per-property time reclaimed by replacing manual rate-management cycles with reviewable recommendations and bounded auto-pilot.
What I’d do differently
- Wire the satellite teams' integration test suite earlier. The PWA was the canary, but a shared contract-test suite running in CI for every satellite would have caught the two pre-prod regressions in CI rather than QA.
- Treat the GTM playbook as a product, not a doc. APAC → UK → US worked, but the playbook lived in Notion. Wrapping it in tooling (rollout scoreboard, automated cutover gates) would have saved a week per region.
- Quantify the satellite leverage at decision time. "Single API surface unblocks 7 products" was rhetorically strong but only post-hoc obvious. A discounted-cash-flow view per satellite would have been the right artifact to defend the platform investment in P&L review.
Related work
