Denshin / Blog / Case Studies
Field notes from building a houseboat booking system in Kerala
Pricing as a function, internet that comes and goes, and the booking flow that starts as a WhatsApp message: what we learned shipping a real-world reservation system on the Kerala backwaters.
Denshin Team · Product & Engineering · 5 April 2026 · 2 min read
Most of what we read about online booking systems is written by teams who built one in the United States, in Europe, or for an enterprise customer. Useful, but the model breaks in interesting ways when the operator is a small family business on the Vembanad backwaters.
A few things we ran into.
Pricing isn't a number
The first thing the customer asked us was, "how do I set the price?" We pointed at our beautiful price field. He laughed. The price for a houseboat in Kerala depends on the number of bedrooms requested, the number of guests, the season (Onam and Christmas alone have their own rules), the day of the week, and whether the booking comes through a particular travel agent. Our flat price column was wrong on day one.
What worked was treating pricing as a function (a small object describing rules, evaluated at booking time), rather than a number stored on the boat. The admin panel lets the operator manage rules, not numbers. The mental model changed: instead of asking "what does this boat cost?" the operator asks "what does this booking cost?" That's a much smaller conceptual leap once you've had it pointed out.
Internet that comes and goes
The houseboat itself doesn't have stable internet. Confirmation flows that assume a real-time API call between phone and server fall apart. We moved to a model where bookings are confirmed locally on the operator's phone, queued, and synced when the phone gets signal back at the jetty. Boring software, well-known in offline-first circles, deeply unfamiliar to teams who have never had to think about it.
The unexpected upside: the offline-first model also handles the case where our backend is having a bad day. The operator never noticed.
WhatsApp is the channel
Customers don't email. Customers don't fill out forms. Customers WhatsApp. The booking system that pretends otherwise loses to the system that understands the booking probably starts as a WhatsApp message and ends as a confirmed reservation in our database, with a human in the loop. We built the admin around that flow, not around the form.
The lesson, which we keep relearning: a booking system isn't an abstract domain. It is the operator's actual workday made faster.
What we'd do differently
We over-engineered the calendar UI in the first version. The operator never used it. He looked at his WhatsApp, looked at the dates, and typed them into a form. The fancy drag-to-select calendar was lovingly built, deeply ignored, and eventually replaced with two date inputs. Cheaper, faster, used. Sometimes the right thing is the thing that doesn't show off.
Tags: Case Study, Travel, Booking, Kerala, Offline-First
All posts · Work with Denshin