A reference build: we made this ourselves to show how we work. It is not a client engagement, there is no customer to name, and there are no measured outcomes to report - so this page does not pretend to have any.
The booking engine that knows about Saturdays
A reference build: a direct-booking flow whose availability engine expresses the rules a template cannot - seasonal minimum stays, changeover days, and a refusal to create an unsellable gap.
- Client
- Reference build
- Sector
- Hospitality
- Year
- 2026
- Built with
- Next.js, TypeScript, Postgres, Stripe, Viva Wallet
The numbers
- 4
- Rules the engine expresses that a template cannot: seasonal minimum stay, closed-to-arrival days, changeover, orphan gaps
- 3
- Places the same availability code answers: the calendar, the price quote, the final booking
- 0
- Second validators, because two is how an overbooking happens
The problem
A villa portfolio takes its bookings by email because no off-the-shelf engine can express Saturday-to-Saturday changeover, and a hotel takes a two-night booking in August that strands a single unsellable night either side of it. Both are availability-logic problems, and both are why the property is paying 25% commission on demand it already owns: the OTA can express the rule, so the guest books there.
What we did
- 1
The availability engine is a separate, pure module with no UI in it, so every rule is testable in isolation and the same code answers the calendar, the price quote and the final booking. An engine that validates differently at those three points is the single most common source of overbooking.
- 2
Orphan-gap detection refuses a booking that would leave fewer nights than the season's minimum stay before the next reservation. It costs a booking occasionally and it protects a week regularly, which is a trade the owner gets to set rather than us.
- 3
Rate parity is respected and routed around by design: the engine cannot undercut the OTA rate, and instead attaches value - transfer, late checkout, returning-guest tier - because that is what the contracts permit and what actually converts.
- 4
Deliberately not built: a PMS. Arrivals, housekeeping and folios stayed where they were, and the engine talks to the channel manager already being paid for.
Where it got to
The rules tab of the calculator on the hospitality page is this engine's logic, running in your browser. Try to book two nights in peak season, or arrive at a villa on a Wednesday, and you get the same refusal and the same reason a guest would.
A worked example
The rules tab on the hospitality page is this engine. Peak season, nights 6 to 8 already sold:
- Three nights from Sat 1
- refused
- Reason
- 2 unsellable nights left
- Three nights from Sun 2
- refused
- Reason
- closed to arrival
- Three nights from Mon 3
- accepted
The refusals are the product. An engine that only says fully booked sends the guest to an OTA that can express the rule.