The one where we shipped no AI at all

The situation

Roughly a hundred property owners on a remote island chain, several hundred rooms between them, and a few hundred travel agents across the country who sell those rooms. The entire market ran on spreadsheets, paper diaries and phone calls. An agent rings an owner to ask what's free. The owner checks a book. Sometimes the book is wrong. Sometimes two agents sell the same room.

One fact decided most of the architecture: the owners are not tech-forward people. Any solution that required them to change how they work was going to fail, regardless of how good it was.

The decisions

Every meaningful choice here came out of understanding the operators, not out of a technology preference.

• We kept the spreadsheet

  The instinct in this situation is to replace the spreadsheet. It's the visible symptom, after all. We did the opposite. Every owner still gets a spreadsheet, mirrored automatically from the database into their own cloud drive, laid out as a calendar grid because that's how they read their existing paper diary. The database is the source of truth; the sheet is how they check it. It's one-way, and it can never block a booking from being written.

  An owner who doesn't trust the new system can keep looking at a spreadsheet forever and still be inside the system. Adoption stopped being a fight.

• We keyed agents by company, not phone number

  The obvious engineering choice is the phone number: unique, normalizable, already collected. It's the wrong answer here. Agency staff change and numbers churn, so phone-as-identity quietly generates duplicate records for the same real business, and an owner looking at their bookings sees one agency fragmented into four.

  Owners think in terms of "Bingo Travel," not "+91…". So the company name became the identity and the phone number became metadata. That distinction is invisible in a demo and decides whether the data is usable in a year.

• We shipped zero AI

  There was nothing here that needed interpretation, generation or reasoning. What was needed was a shared calendar that two parties could trust, and an overlap constraint enforced at the database level so that a double-booking is impossible rather than merely unlikely.

  A model would have added cost, latency, a support burden and a new failure mode, and solved nothing that a constraint doesn't solve better. Being able to say that out loud to a client, in a market where every vendor is selling AI, is most of why they trust the rest of our advice.

• We made the first phase free

  The gating risk was never revenue. It was whether non-technical owners would adopt anything at all. Charging before that's proven optimises the wrong variable and gives every hesitant owner a reason to say no.

What we'd point at

The work that mattered here was understanding how a hundred non-technical operators actually run their day, then removing things from the build until what was left was something they'd genuinely use.