Since 27 March, the lodge I started and run in the Maasai Mara, Mara Hilltop, has put 600 bookings, 311 tax invoices and 63 tour operators through KaribuKit, the hotel software we build in Kenya. In August I wrote up three bugs our own front desk caught. This is the wider picture at the six-month mark, including the parts that still don't work.

When I say AI-native I mean four rules.

• Anything a person can do on a screen, a model can do through the same system, on that person's own key. About ninety operations today.
• Every price a model says out loud comes from the rate table for real dates, never from memory.
• A person is on every send. Nothing reaches a guest without one of us.
• Every write leaves an audit trail, and the model isn't allowed round it.

The scoreboard, 27 March to 17 September

Nobody typed a Booking.com reservation into a calendar in six months, and nobody released a cancelled one either. The 122 cancellations are what free cancellation looks like from the lodge side: guests book three places and drop two, and each drop has to give its room back the same minute or you double-sell it in high season. The one time that got awkward, an OTA booking that fit in no single room, is in the August post.

Every one of the 311 invoices was filed with KRA through eTIMS straight from the folio, with no separate accounting step, and came back carrying KRA's receipt number and signature.

WhatsApp is the channel that matters here. In July we measured every message the lodge had sent or received since March, about 19,000 across 721 chats, and the median time to a first reply was four minutes, on three people's phones. That number was already breaking when we measured it: two minutes in May, thirteen in the first week of July, when high season landed on the same three people. Since early August every WhatsApp message and every email to hello@ lands in KaribuKit's inbox, normally within five minutes, where a model reads the thread, writes a one-line summary and tags what we owe: a quote, a transfer time, a payment link, a voucher. The reply is still a person's.

The chat on the website had 190 conversations by 11 August. Its first three months produced twenty-four full quotes with dates and prices and one confirmed booking; by August a second guest had booked inside it, at least three leads it saved had become stays, and three others had sat untouched for weeks until I went looking, which was on us, not the bot. It can check real availability, quote a stay from the same rate table as the desk, and hold a room as tentative. It can't confirm, cancel or discount anything.

What the four rules look like at a front desk

The rates for all of 2027 went in one afternoon in July, through a chat window: about a hundred writes across every season and room type. I didn't approve them row by row. I told it which mistakes were cheap ("as long as it's not crazy pricing like $100 for the Lux room") and checked the result afterwards. On the way through it noticed that our most expensive three weeks, 21 December to 10 January, had no luxury-tent override at all and were quietly selling at $320 a night instead of $340. Every operation a screen offers is also available to a model on my key, with my permissions. A boring hundred-row job takes an afternoon, and the model reads every row while it's in there, which is more than I do.

The second rule came out of a failure. In August we ran the website chat against its own instructions, and in one run out of four it quoted a visitor the base rate for an October stay, $95 above the October price, even though the no-quoting rule was written into its instructions in two places. A prompt holds most of the time, and most of the time isn't good enough for money. So the rule is now structural. Every price the chat states has to come from a lookup for the exact dates in that same conversation, and the trip planner goes further: its model never sees a price at all, the pricing engine fills the numbers in afterwards. Ask for "early October" and it picks the 5th and tells you it did.

In the inbox the model reads and tags, and that is where it stops. When one of us opens a thread, an assistant drafts the reply in our voice from a playbook built out of 682 real conversations, with every price and policy pulled from the system. Then we read it and send it, or rewrite it. The warmth and the judgement calls stay with us, and the model can never promise a guest something the lodge doesn't do.

In July two groups had been created for the same party, with the one real $1,760 bank transfer on one and a duplicate cash entry keyed onto the other. I told the model, twice, to fix it from the database. It declined both times and used the reversal path, so there's a record of what moved where and the tax system isn't lied to. I'd asked it to break the fourth rule and it wouldn't, which is the point of having it. The payments module is built the same way: a payment it can't match to a folio lands in a queue that shouts until a person clears it, and nothing gets quietly dropped.

One more thing that's a decision rather than a rule. The chat on the website, the chat a booked guest gets, and the copilot in the staff app are one persona, Ranger, with the same rate table and the same limits. And the pricing engine behind the proposals module, the one that prices a multi-lodge trip from a sentence, now also runs the trip planner on marahilltop.com and on RafikiGo, the small trip company we run alongside the lodge: a day-by-day Kenya itinerary from one message, every line priced from a contracted rate or handed to a person.

The Kenya part

Most hotel software is designed somewhere else and adapted to Kenya afterwards, if at all. This is the table I'd want from any vendor. We sell the thing, so read it as a vendor's table.

The last row decides more conversations than the AI does. The two shapes you'll meet elsewhere are a share of every booking, which is what HotelOnline's "pay as you go, no fixed fee" means (it bought HotelPlus and says it has 6,000 hotels), and a per-room price with a minimum room count, which is how the big imported systems sell. We charge one flat monthly fee, agreed per property, and no percentage of anything, because a lodge that has a good season shouldn't pay more for the same software.

What it doesn't do yet

It doesn't reply on WhatsApp by itself. The inbox reads, summarises and drafts, and a person sends every message. There is no voice channel. And Mara Hilltop is the only lodge live on it, on purpose: we wanted the first six months to be about running stable and steady on our own property before putting anyone else's guests on it. We're now at the point where we're happy with how it's functioning, a second lodge is onboarding, and we're looking to expand to a few more.

It has failed in ways we've written up rather than hidden. A reservation went invisible on the calendar. A folio showed $591.82 when the card held $573.10. An OTA booking arrived that fit in no single room. The booking page took eight seconds for six months because of one database setting. The inbox feed died for 41 hours in high season while the health check reported everything fine. The website chat once said "Noted!" about a request it had no way to note. That's six failures in public so far: three in the first post on this blog, two on the lodge's blog, one on our engineering blog. A vendor that can't publish its failures is asking you to take the successes on trust.

If you run a lodge or a camp in Kenya, we'll build a working copy of your booking page on KaribuKit with your own rooms and rates loaded, so you can see your property in it before you decide anything. The WhatsApp button is on karibukit.com.

As I write this, on the afternoon of 17 September, the inbox shows at least seven threads from the last twenty-four hours that we owe a reply on. The oldest is a tour operator waiting to hear that five rooms are held for October. That's the next thing I do after posting this.

— NJ

At 7:13 on the evening of Sunday 14 September a guest messaged Mara Hilltop, our lodge in the Maasai Mara, with a screenshot. Chrome on his iPhone, an error page in Spanish, and an apology for the Spanish. He had picked his dates on marahilltop.com and pressed Continue, and the page died. He tried again and it died again. That, he said, was why he was writing to us on WhatsApp at all: he couldn't go forward on the website.

I couldn't reproduce it on my laptop, which I think is how most booking-page problems stay unfixed: the owner checks on a desktop, it works, and the guest on a phone gives up and books somewhere else. This one got fixed that night, and fixing it turned up a second problem that had been making every screen in KaribuKit, the software we build and run the lodge on, slower than it should be.

Why his phone gave up

The error he sent is what an iPhone shows when a page has used so much memory that the browser kills it, twice in a row. Our booking page was the reason. It loaded the original camera files for every room photo, and the moment the rooms appeared it fetched the full gallery of every room type, whether the guest opened a gallery or not. I downloaded the same 36 files the page pulls and measured them: 47 MB to download, and 3.9 GB once a phone unpacks them into pixels to draw them. Fifteen of the photos are 8,000 pixels wide or more. One tent interior on its own is 186 MB unpacked.

A laptop has the memory to hide that. A phone does not.

The fix was ready before the guest wrote. We had hit the same crash on a different page in August and written the change: serve resized copies of each photo instead of the originals, and stop preloading galleries nobody asked for. It sat unmerged for nineteen days because my own notes said it was done. It went live that night. The page now loads no original files at all, and the largest image on it is 1,024 pixels wide.

The second problem, which was worse

While checking the fixed page I timed the availability request, the call that asks the system which rooms are free for the guest's dates. Ten seconds. Not on a slow connection in the Mara either, but on the server itself.

The cause was one line of database setup, wrong since launch week in March. Because of it, every question the system asked the database took about a quarter of a second instead of the fifty milliseconds it should. The booking page asks 38 questions in a row to build one availability result: six room types, and for each one, is a room free, what is the rate, are there overrides for these dates. Thirty-eight quarter-seconds is where the ten seconds came from.

We had measured that cost in March, four days after go-live, and blamed the distance between the server and the database. We then spent months trimming how many questions each screen asked, which helped, without touching what each question cost. The engineering version, with the database statistics and the exact setting, is on the SimbaStack blog: Every database query cost us four round-trips for six months. The owner's version is that the fix was one setting, changed at 23:40 Nairobi time, with no code touched.

What changed

Medians from the system's own logs, the three days before the change against the eighteen hours after it:

Nothing else changed: same server, same code. The setting is shared, so every screen got it at once, not just the booking page. Next is asking those 38 questions at once instead of one after another, which should put the booking page under a second.

How to check your own booking engine in two minutes

You don't need a developer for this.

1. On your phone, on mobile data rather than the office wifi, open your own website and go through to the point where you pick dates and see rooms with prices. Count the seconds from tapping Continue to seeing rooms. Under three is where I'd want to be. Ours was eight, and the guest who wrote to us got a crash instead of a room list at the end of it.
2. Open a room's photo gallery and swipe through it. If the phone gets warm, the page reloads itself, or each photo takes a second or two to sharpen, the page is loading original camera files.
3. Ask your vendor for the number. Any system can log how long the availability call takes. "What was the median availability response time for my property this week" is a fair question, and if your vendor can't produce the number for your property, that is itself the answer.

Borrow a phone that isn't yours for step 1. The phones that fail belong to guests, and the one that failed here had 81 tabs open.

What this doesn't prove

Running our own lodge on the software didn't stop us shipping an eight-second booking page to our own guests for six months. It got caught because one guest bothered to message, and we had lived with the second problem the whole time without finding it. It doesn't prove the software is fast now, only that most screens are three to four times faster than they were last week, and the one the guest waits on 4.3 times; under a second is the target and we are not there. And I don't know whether he booked. He had a reply at 7:14, the page fix was live that night, and he had a message saying so at 12:03 AM.

If you run a lodge in Kenya and want to time our booking page against yours, message us on WhatsApp via karibukit.com. We'll show you ours first.

— NJ

NJ runs Mara Hilltop, a lodge in the Maasai Mara, and builds KaribuKit, the property-management system it runs on.

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:

1. 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.)
2. 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.)
3. 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.)
4. 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.