We run our own lodge on the software we sell
Every hotel software vendor says some version of "built by hoteliers, for hoteliers." It's on half the websites in this industry, and it's unfalsifiable, which is why it appears on half the websites in this industry. So let me make the claim in a form that can actually be tested: our lodge, Mara Hilltop in the Maasai Mara, has run on KaribuKit since March 27, 2026. Real guests, real OTA bookings, real KRA invoices, and now our first high season on it, underway as I write this. When the software fails, the guest standing at the desk is mine, and so is the staff WhatsApp group that lights up.
That arrangement sounds like marketing until something breaks. Then it turns out to be the whole quality system. What follows is three failures our own desk caught, and one feature dogfooding told us not to build, with the failures left in, because the failures are the point.
The reservation that went invisible
July, high season, the lodge close to full. A staff member is rearranging rooms and moves the second room of a guest's two-room booking. The reservation vanishes from the calendar. Not flagged, not greyed out. Gone. The booking header still says two rooms; the calendar shows one. If you've ever run a full lodge you know exactly how bad that is: an invisible reservation is a double-booking waiting for the worst possible evening to happen on.
The cause took a few hours to dig out. Months earlier, a duplicate of one room had been created under a room type we'd since deactivated. The room picker still offered both copies, near-identical down to the name, and the staffer landed on the phantom. The calendar only draws rooms belonging to active room types, so a reservation sitting on a phantom room had nowhere to be drawn, and the calendar dropped it without a word.
We moved the reservation to a real room the same day, kept the pricing untouched, and confirmed everything rendered before anyone checked in. Then we fixed the actual hole, so no picker anywhere in the system can offer a room from a deactivated type, with regression tests that fail if it regresses.
The fix mattered less than what the incident taught us. A crash gets reported in minutes; this thing failed silently, showed everyone a plausible wrong picture, and got caught only because the person who noticed something odd could walk over and say so. Any system that can lose a booking quietly is more dangerous than one that breaks noisily.
The booking that fit in no room
Booking.com computes availability night by night. It's entirely happy to sell a three-night stay when your lodge has a room free each night but no single room free for all three. From the platform's arithmetic, you have space. From your floor plan, nobody can sleep in the corridor between room moves.
Our first version of the channel sync treated that as an error and refused the booking. Correct by the data model, and completely wrong operationally, because the refusal jammed the connection and the property's queue of channel updates stalled for about an hour behind it. A stalled queue means your real availability isn't reaching the OTAs, which is how overbookings actually happen. We'd built a system that responded to an awkward booking by making everything less true.
The fix, and I say this as the person who initially argued for a cleverer placement algorithm, was to stop trying to be clever: accept the booking without a room, flag it loudly, and let a human decide the room moves. A person at the desk solves that puzzle in thirty seconds with knowledge no algorithm has, like which guest won't mind switching tents after a game drive. And because the room-less booking still decrements what we're selling, the double-sell protection holds on its own.
As an operator, at 7am, what you want from your software is the booking safely in the system and a clear flag saying "needs a human." Software that tries to be smarter than that ends up refusing money.
The number the desk didn't trust
The quietest bug is my favourite, because of how we found out.
For a stretch, four of our Expedia folios displayed a balance of $591.82 while the virtual card Expedia had issued actually held $573.10. The difference was withheld VAT our display logic didn't account for. No crash, no error. Just a number that was wrong by $18.72.
Our front-desk team didn't report it. They worked around it. They took to opening Expedia's extranet before charging any card, checking the real amount there, and charging that. Sensible people doing the sensible thing, and a complete indictment of the software, because a folio number the desk verifies somewhere else is a folio number that has failed at its only job.
I found out over dinner, not through a ticket. That's the entire argument for running your own lodge on your own product, in one scene. Software teams talk about feedback loops; there is no loop shorter than your own staff mentioning, mid-meal, that they stopped believing your numbers. The payout logic got rewritten so the folio shows what's actually on the card, and the wrongness never spread beyond those four bookings to a paying customer's property.
The feature we didn't build
One more, from the other direction. A teammate asked whether a folio could be updated after checkout, for the classic case: a charge surfaces after the guest has left. My first instinct was to spec a proper post-checkout amendment feature. Before building, we traced what the system could already do, and it turned out the capability existed end to end through split folios; the only thing genuinely missing was a button. The guard everyone assumed made it impossible was sitting on a different path entirely.
So we didn't build it. One incident isn't a pattern, and a lodge doesn't need its software growing features that already exist under another name. I count restraint as a dogfooding win too: an operator's software budget is finite, and every unnecessary feature is paid for by a lodge somewhere, in complexity if not in cash.
Questions to ask any PMS vendor
These come straight from the stories above, and they're more revealing than a feature checklist:
- If a reservation can't be displayed for any reason, what happens? (The only good answer involves a loud warning. "That can't happen" means it fails silently.)
- What does the system do with an OTA booking that fits in no single room? (Reject, hide, or accept-and-flag. Only one of those is safe.)
- On a channel-collect booking, which number does the folio show: what the guest paid, or what's actually on the card? (If the vendor doesn't understand the question, their folios show the wrong one.)
- When did the people who built it last stand at a front desk running it? (Not "consult for hotels." Run one.)
What this doesn't prove
Honesty requires the last word to cut the other way. Running our own lodge didn't prevent any of these bugs. We wrote every one of them. What it changed is where and how fast they surfaced: at our desk instead of a customer's, in hours instead of months, from people who could lean over and tell me. Dogfooding is a detection system, not a quality guarantee, and anyone selling it as the latter is doing the "built by hoteliers" thing again with extra steps.
The real test is transfer. Our second property goes live later this year, and that's where we learn which of these lessons were general and which were just Mara Hilltop's shape. If you run a lodge in Kenya and want to see the system with our own property's live data on the screen, message us on WhatsApp via karibukit.com. The demo is our actual front desk.
— NJ
NJ runs Mara Hilltop, a lodge in the Maasai Mara, and builds KaribuKit, the property-management system it runs on.