Our own tool · Hospitality · 2026
The booking engine that knows about Saturdays
The OTAs take 15 to 18% headline, and up to 30% once the visibility programmes stack. This is the booking engine that wins back the guests who already knew your name - including the stays a template refuses and an OTA happily takes.
4
Rules the engine expresses that a template cannot: seasonal minimum stay, closed-to-arrival days, changeover, orphan gaps
- Next.js
- TypeScript
- Postgres
- Stripe
- Viva Wallet
Try it here
This is the same code that runs on the sector page, not a recording of it. Put your own numbers in.
- Start from a property like yours, or set your own rooms and rate.
- Drag the share you would win direct and watch the payback move.
- On the availability rules tab, try a stay an off-the-shelf engine would accept.
0/3
Real arithmetic, running in your browser, on figures you control. Nothing is sent anywhere. The defaults are industry ranges, not your property - change them.
The numbers
- 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
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.
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.
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.
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.
Try it hereWant something like this for your business?
A 20-minute call with the two people who would build it. You tell us what you need; we tell you whether it is worth building and roughly what it costs.
The full page: Hotels & hospitality