Real Hotels Group
One content backend, every hotel its own site
A multi-tenant CMS where each hotel's editors manage pages, rooms, restaurants, offers and event spaces, and every hotel website ships independently against one shared, versioned content API.
- Client
- Real Hotels Group
- Year
- Type
- Multi-tenant CMS & content API
- Role
- Product design, build, and platform operations
- Views
- 46
Context
Why did Real Hotels Group need this?
Running one website per hotel meant one CMS per hotel, with duplicated editorial models, duplicated hosting and no shared upgrades. RHG needed hotel teams to own their content without every site owning a backend.
Product
What did we build?
A multi-tenant CMS on Payload with a versioned REST facade: 13 collections, four content locales, tenant-scoped access control, and a published typed SDK so each hotel site is a standalone frontend against the shared backend.
Experience
What is it like to use?
Hotel editors work in their own tenant, covering pages, rooms, restaurants, experiences, offers and event spaces, in a PT/EN admin. Publishing updates the consuming site straight away. The first hotel site built on it is live against the production facade in four languages, with typography and theming configurable per tenant from the CMS.
Engineering
How is it built?
Each hotel's content is walled off from every other one, and that separation is checked on every single request rather than assumed. A new hotel site starts from what already exists instead of from nothing, and each site chooses when to take an update, so one going live never forces the others to move.
Outcome
What changed?
New hotel sites start from a typed SDK and a live content API instead of a new backend. The platform runs in production with its first hotel site consuming it.