June 12, 2026
Picture an operator at the kitchen table on a slow night, a notebook open, trying to answer one question before they sign anything: what is FareHarbor actually going to cost me? They have heard the demo. It was good. But it did not put a number on the page, so now they are reverse-engineering the price of running their business on it, and cannot quite get there.
I have been that person at that table. So let me do the math the honest way, because the sticker price is rarely the cost.
When you ask how much FareHarbor costs, you are usually hunting for a monthly fee, the way you price a phone plan. You will not find one, and that is not a trick. FareHarbor charges a per-booking fee that gets passed to the guest in the standard booking-fee model, and they handle card processing as part of that. For modeling, many operators use a number around six percent because that is what shows up in forum discussions and competitor comparison pages. FareHarbor does not publish one universal public percentage, so treat six percent as a modeling assumption to confirm against your quote, not their published rate.
So the real answer is not a price. It is a structure. A transaction model means the more you book, the more the system earns, forever. A flat SaaS fee means you pay the same in a dead August as on a four-ship cruise day. Neither is evil. But they are very different bets, and a lot of operators I talk to never run both versions of the math.
Forget the brochure. Sit down with your actual numbers. Say you run a six-passenger private charter at four hundred dollars a trip. If we plug six percent in as a working assumption, that is roughly twenty-four dollars on top of that charter, before card costs. One trip, who cares.
Now stack a season on it. Say a hundred and fifty bookings a month at that price, and your fee column is suddenly four figures every month, and it keeps scaling the whole time you're growing. That is the part the demo does not draw for you. A percentage feels small on one trip and enormous across a year.
And before you decide that is good or bad, ask who pays it. If the fee is passed to the guest, your margin is safe but your booking-page price just went up against the operator down the dock who eats it himself. If you absorb it, your price stays sharp but the percentage comes out of the trip. There is no free version of this. Only choosing where the cost lives.
Back in 2012 I was running SXM Deals, a site I built to book tours and charters across St. Martin. A group came in wanting a big private charter. Real money, the kind that pays your month. I did not want to take their card before the operator confirmed he had the boat and the crew, because if he did not, I was refunding a small fortune and eating the chargeback. So I emailed him. And waited.
Two days. Not two minutes. Two days. The guests sat there not knowing if their charter was even happening, because the workflow ran on email and a captain elbow-deep in salt water cleaning his boat. By the time he wrote back, the moment had cooled and the money was at risk. I should have had an answer in two minutes.
That is the day I understood what software actually costs. The price on the page was never the bill. The bill was the admin time, the friction, the deal that almost evaporated while a workflow ran on email. That is the cost nobody puts in the fee column, usually the biggest line.
When operators ask me what a booking system really costs, I tell them to write two columns. One is fees. The other is everything fees do not cover, and that second column is where the real money lives.
That middle one is the one that gets me. A lot of booking software is built for Stripe-supported markets where the payment rails are simpler. In parts of the Caribbean, that support varies island by island - Stripe is not available in several Caribbean territories at all, even when it works fine on the next island over. I have watched serious operators route card payments through Stripe into a bank account in the US or Canada or Europe, then wire the money home. Even when everyone means well, that creates accounting, tax, FX, and payout questions operators should not have to solve just to take a card online. Booking tools tend to lean on whatever processor they support, whether that is Stripe, Adyen, or PayPal. For an operator outside the US, that friction is a real cost, and it never shows up next to the booking fee.
I am not going to pretend a transaction model is wrong, because we use one too. When we launched Junglebee, I wanted a flat monthly fee because it made my revenue easy to forecast. The operators pushed back hard. A flat fee, they told me, is just a tax on a slow August. So we switched to per transaction, only on bookings where we process the payment. In the Caribbean markets we support, we pay funds out to the operator's own local bank account. The transaction-fee structure is on the pricing page, and our country pages explain the local-bank payout setup for each island we support.
So I am not telling you to fear the percentage. I am telling you to run the whole bill. Take your real volume, build the fee column honestly, then add the column nobody adds: the admin hours and the route your money takes home. The cheapest sticker can still cost the most once time and money flow are in it.
That is the lesson the two days taught me. The price on the page is not the cost. The cost is whether your business answers in two minutes or two days, and where your money sleeps at night. Run that math, and what FareHarbor costs answers itself.
