Hospitality software an independent property can run.

Hospitality software has a built-in trap: the data model is genuinely complex — rooms, room types, units, rate plans, mappings, inventory — so the interface becomes a mirror of the database. I design hospitality SaaS that stays usable for a property with one person on the front desk.

Start a project

DesignBuildGrowScale

One continuous process. One partner.

Not four services — four stages of the same product.

01 — Work

What's shipped

Live products in this sector — verifiable from the store listing or the product itself.

Product & PlatformHospitalityLive

A hotel management system covering rooms, rate plans, inventory and reservations — designed so an independent property can run it without training.

Rooms, rates, inventory and reservations in one operator console

Websites & BrandTravel & tourismLive

A travel operator's full catalogue — destinations, packages and themed holidays — organised around the three different ways people start planning a trip.

4.9★ across 612 Google reviews, surfaced on the site

02 — The domain

What hospitality software demands.

The constraints that don't show up in a generic design brief, and decide whether the product works in the field.

  • 01One object per screen. Rooms, room types, rate plans, mappings and inventory are all separate things. Showing them all at once is how these products become unusable. Each screen leads with one object; everything else is a relationship to it.
  • 02Price and availability together. The question a property asks every day — what am I selling tonight, and for how much — should be one glance, not three screens. The rate calendar puts both on the same grid.
  • 03Adopted without training. The buyer is an independent property, not a chain with an IT team. They evaluate it alone and abandon it the first week it's slower than the spreadsheet it replaced.
  • 04A hierarchy the operator can see. The sidebar exposes the structure rather than hiding it, so operators build an accurate mental model in the first session instead of guessing for a month.

03 — How I'd help

The engagement

An industry frames the work; the engagement is one of these.

Compare engagement models

04 — Questions

Common questions

PMS, channel manager, booking engine — which do you design?
All of it is in scope. MyHotelio covered rooms, rate plans, rate mapping, inventory and reservations. Channel-manager and booking-engine surfaces follow the same principles.
Do you integrate with OTA and channel APIs?
I design the surfaces and states around an integration — mapping, sync status, conflicts, errors. The integration itself is engineering: your team's, or a front-end build I do against the provider's API.
Independent properties or chains?
The bias in the portfolio is toward independent and small-group properties, where usability is survival. Chain tooling is in scope with different assumptions about training and support.
Can you build it, not just design it?
Front-end in React and Next.js, yes — see Figma-to-React development.