This is the first thing I’ve written on this blog, so let me start where the whole idea started: standing in the heat outside a villa on an island resort, watching a guest wait for a buggy that nobody could tell them was coming.
She’d called the front desk maybe eight minutes earlier. The receptionist had keyed a radio, a driver had answered, and then — silence. Not because anyone dropped the ball, but because that’s how the system works. The request lived for a few seconds as sound in the air and then disappeared. The guest didn’t know if she’d been heard. The driver was already on another run. The front desk had moved on to a check-in. Three people, all doing their jobs well, and the result was a woman in the sun checking her phone for a confirmation that was never going to arrive.
I’ve spent a lot of my career around hospitality operations, and I’d seen that exact scene more times than I could count without ever really seeing it. It just looked like part of the furniture of running a resort. The day it finally registered as a problem — a specific, fixable problem rather than a fact of life — is the day Resort Buggy began.
The thing I couldn’t stop noticing
Once you see the radio-dispatch gap, you can’t unsee it. I started paying attention everywhere I went: the boutique island property with three buggies and a single overworked radio, the golf club where the starter doubled as an unofficial dispatcher between tee times, the larger resort with a dedicated transport desk that was still, at heart, a person broadcasting villa numbers into the void and hoping.
The pattern was always the same, and so were the symptoms. Guests waited without information. Front desks burned real hours acting as a human switchboard. Drivers ran on a queue that existed only in their heads, which meant two buggies sometimes converged on one villa while another guest stood forgotten at the far beach. And — this is the part that nagged at me most — nobody had any data. Ask a general manager what their average pickup wait was and you’d get a shrug and a guess. Not because they didn’t care. Because the radio writes nothing down.
What struck me wasn’t that resorts were doing this badly. They were doing it about as well as the tools allowed. The problem was the tool. A two-way radio is a broadcast voice channel, and somewhere along the way the industry started using it as a queueing system. Queues need three things radios fundamentally don’t have: memory, structure, and feedback. You can be the most disciplined dispatcher alive and you still can’t give a radio a memory.
The realization that made it a company
Here’s the insight that turned an annoyance into a conviction. The problem I was looking at had already been solved — just not for resorts.
A decade ago, urban ride-hailing took the exact same mess — riders with no idea when a car was coming, drivers negotiating over who takes what, no record of anything — and fixed it. A request becomes a persistent object. It gets offered to the right driver automatically. The rider watches the car approach on a map. Everything gets logged. We’ve all internalized this so completely that we forget it was ever hard.
So I asked the obvious question: why hadn’t that pattern reached the resort? And the answer, once I dug into it, was genuinely interesting. The big ride-hailing platforms are enormous — and most of that enormity is stuff a resort doesn’t need and doesn’t want:
- Payments. The single most complex part of any ride-hailing system is moving money — pricing, surge, cards, payouts, fraud, refunds, tax. But on a resort, the ride is complimentary. It’s part of the stay. There’s no fare. Strip out payments and a staggering amount of the platform’s weight just falls away.
- Rider accounts. Public ride-hailing needs identity, history, ratings, a marketplace of strangers. A resort guest already checked in at the front desk. They don’t need an account. They certainly don’t need to download an app and create a login for a four-minute ride to dinner.
- An open marketplace. Public platforms match anonymous supply to anonymous demand across a whole city. A resort has a known, fixed fleet on a known, fixed property. The matching problem is dramatically simpler.
When I lined those up, the conclusion was almost startling in how clean it was: the urban ride-hailing pattern scales down to a private property beautifully — but only once you strip out the three heaviest parts. What’s left is the elegant core: a request, an automatic offer to a driver, a live map, a log. That core is exactly what a resort needs and essentially all a resort needs.
That was the moment Resort Buggy stopped being a thought and became a thing I had to build.
The temptation we deliberately walked past
The easiest mistake to make here — and I want to be honest that it was tempting — would have been to build a platform. Add a payments module “for the spa.” Bolt on housekeeping requests. A concierge marketplace. Loyalty points. Inventory. Pretty soon you’ve got a sprawling property-management suite with a buggy feature buried in a settings menu, a six-month implementation, and an enterprise contract with a sales engineer attached.
I’ve watched that movie. The hospitality software graveyard is full of bloated platforms that do twelve things adequately and the one thing you actually needed poorly. So we made a decision early and we’ve held it like a religion: Resort Buggy does one thing, and does it so well it disappears.
One thing means a guest scans a QR code in their villa and the booking screen opens right in their browser — no app store, no download, no account, no password. They pick where they are and where they’re going from your property’s own named locations — “the beach bar,” “Villa 23,” “the spa” — the way guests actually talk, on your own map. The system offers the ride to the nearest free driver, who taps accept. The guest watches their buggy approach on a live map, with a notification when it arrives. And every single ride — request time, wait, route, driver — writes itself to a dashboard the GM can finally read.
No fare screen. No card on file. No marketplace of strangers. Rides are complimentary, because that’s what they are at a resort. We took the thing out of the box and threw away everything that wasn’t the thing.
What this blog is going to be
Since this is post number one, let me tell you what you can expect if you stick around.
I’m writing this for the people who actually run the operation — resort general managers, golf club operations directors, the head of guest services who already knows exactly which villa generates the most “where’s my buggy?” calls. I’m not going to write breathless think-pieces about “digital transformation.” I’m going to write practical, specific, slightly opinionated things about guest transportation: what the radio model really costs you when you put a stopwatch to it, how to stand up an on-demand buggy service in a single afternoon, how to read your own demand data once you finally have some, and the honest trade-offs of every approach including the ones that compete with us.
A few promises about the tone. I’ll use back-of-envelope math and rules of thumb, and I’ll tell you when a number is a rule of thumb rather than dressing a guess up as a study. I won’t invent customers or testimonials to make us look more established than we are. And I’ll try to be useful even to the reader who reads the whole post and decides to build their own version with a Google Map and a Telegram bot — because honestly, understanding the problem clearly is most of the value, and I’d rather you solve it some way than not at all.
An honest invitation
Which brings me to where we actually are, told straight.
Resort Buggy is early. We’ve built the product, it works, and we’re now bringing on our first properties through what we call the Founding Partner Program. I want to be precise about what that is and isn’t, because the hospitality software world is full of fake urgency and invented logos. The Founding Partner Program is real pre-launch exclusivity, and nothing more than that: three to five hand-picked partners — across resorts, golf clubs, and the others as we open them — for operators who want to shape the product while it’s still young enough to be shaped. There are no fabricated customer testimonials on our site. There are no pretend case studies. When we have results worth sharing, you’ll read them here, with the real numbers, and not a day before.
In exchange for getting in early, founding partners get direct access to me and an outsized say in what we build next (after the free pilot, the service starts at $299/month on the Boutique tier). That’s the whole deal. It’s honest because being early is genuinely valuable to a small number of operators, and dishonest scarcity would be a strange way to start a company built on getting rid of the guesswork.
If any of this resonates — if you’ve stood at your own front desk and heard that radio crackle and thought there has to be a better way to do this — I’d love to show you. The demo takes twenty minutes, and it isn’t a slide deck. We build a miniature version of your property, with your map and your villa names, and run a live ride request through it while you watch the buggy move across the screen. That’s it. Twenty minutes, your property, the real thing.
That’s why we built Resort Buggy: so that the woman waiting in the sun outside her villa can glance at her phone and see her ride coming. Everything else is detail. Thanks for reading — there’s a lot more to come.