Bonaca — A Revenue Copilot for Charter Fleets

Bonaca is an early-stage product I'm developing — currently in concept and design. This case study is about the thinking behind it, and the design problems it turns on.

Croatia charters thousands of boats across 1,244 islands — a coastline built for sailing, and an industry that sells it one week at a time. Each of those boats is booked about a third of the year: sixteen weeks out of fifty-two. Which means an empty week isn't a gap. It's the margin.

So when a boat isn't booking, the reflex is the same everywhere: drop the price and hope. Some of those weeks would have filled anyway. Nobody knows which ones — and that's the whole problem.

There's a structural reason it keeps happening. Croatia hits peak occupancy by mid-June; Greece doesn't peak until August. Same sea, two months apart — so Croatian operators are making their hardest pricing calls earliest, with the least information.

What already exists

The tools charter fleets use today are booking systems, not decision systems. The largest — used by over a thousand fleets — has a revenue module, but it compares competitor prices and tracks targets: it shows you the numbers and leaves the call to you. Newer entrants handle operations and turnaround, not pricing. Meanwhile the same problem in adjacent markets is a mature category: revenue management tools price hundreds of thousands of short-term rental listings, and 83% of property managers adjust prices at least weekly.

Nobody was making recommendations with reasoning on the supply side. That gap is where Bonaca sits.

Where it lands

So Bonaca isn't a pricing tool. It's a decision tool. The question it answers isn't "how low do I go" — it's "which weeks am I about to lose, and to whom." It's built for a professional fleet with dozens of boats and someone whose actual job is pricing — not the six-boat family charter deciding by feel.

The hard part was never the data. It was that this product has to be trusted by someone who is about to make an expensive decision while frightened — and every instinct I reached for first turned out to be wrong.

Every tool in this space is a dashboard — a screen full of numbers that leaves the hardest part, the decision, to the user. That's the thing I designed against.

Bonaca has three states instead, each matched to a moment in the operator's year, and each with a different job.

Brief — this week. Not a dashboard, a decision list. The week's calls in one dense, scannable view: each boat a row, with the recommended price, the move, and the few numbers that justify it — occupancy, days out, comparable boats, booking pace. Expand a row for the reasoning and the actions. Accept, adjust, or reject — and the system remembers why.

Panic — when the market drops. The crisis state, for March. One boat at a time, shown as two futures: drop now and lock in a certain, smaller number, or hold for a larger, less certain one. The gap between them has a name — the price of panic.

Season — the year in reverse. A November look back. Where money was left on the table, how the fleet compares to the benchmark, and — the part that matters most — where the system's own recommendations were wrong.

Underneath all three sits the differentiator: the operator can tell the system things the model can't know — "the festival moved," "my German guest always takes week 28" — and Bonaca turns that into a factor, then shows how much the human input changed its own recommendation. An AI that listens back.

A dashboard shows you everything. Bonaca shows you the decision that matters, in the form the moment calls for.

The data is the easy part. Each of these was a design problem before it was a technical one — and on each one, the obvious answer was the wrong one.

Confidence, without percentages. I reached for precision first — "78% likely to fill." Wrong. Under stress nobody feels a percentage; they either ignore it or over-trust it. So confidence became a sea state: a calm line for settled, a ripple for shifting, chop for unsettled. Shape carries the meaning, not just colour, so it survives a bad screen and a colour-blind user. And low confidence became a feature — "not enough signal yet, I'd rather tell you Thursday than guess today" earns more trust than false precision.

Designing for panic. I reached for urgency first — red, alerts, visual weight. Wrong. The user arrives already scared, and adding urgency to a scared person doesn't produce action — it produces a worse decision. So the crisis screen became the calmest screen in the product: no red, no alarms, more whitespace than anywhere else. It narrows focus to one decision, names the trade-off in money, and never blocks the panic move. "Drop anyway" sits right there, quiet and unjudged. Sometimes locking in cash today is the right call — and a tool that overrides you once doesn't get opened twice.

Accountability. My instinct was to keep the system's misses quiet — nobody markets their errors. Wrong again. In November, Season lists the calls the system got wrong and what they cost — plainly, in the first person, without excuses. A tool that's never accountable never gets trusted twice.

And the one still open: two users, opposite interests. The operator wants yield; the boat's owner wants to know why their boat sat empty. Same data, read two different ways. Designing a second, read-only view for the owner — without turning the operator's tool into a place they get second-guessed — is the next problem.

None of these are data problems. They're trust problems. That's the whole product.

‍

Bonaca is in active design — researched, structured, and still moving. Not shipped. The thinking is real; the pixels are still finding their final form.