Work · Case study 03 · Palapa Tours · Shipped
Custom tip-out software, shipped.
Gratuity splits shifted cruise to cruise and were hard to reconcile fairly. The rules existed in someone's head, the totals were worked out after a long shift, and the result was disputes among staff over what each person was owed.
- Client
- Palapa Tours Ottawa
- Sector
- Floating tiki-bar cruises
- Status
- Shipped, engagement closed
- Built
- Custom tip-out software that calculates, splits and tracks staff gratuities automatically
- Stack
- Custom build, owned by the client
- Problem solved
- Tip-out variance and payout disputes
01 · Context
A bar that floats, with a new crew on every sailing.
Palapa Tours runs floating tiki-bar cruises in Ottawa. Each sailing is its own shift: guests board, the bar serves, the deck works the room, the boat comes back, and the crew is paid out before everyone goes home. Cash and card sit side by side, and the roster is not the same twice.
02 · The old way
Arithmetic done at the end of a shift by someone who wanted to go home.
The rules existed in someone's head. Totalling gratuities across cash and card, then dividing them by role, was manual arithmetic worked out after a long shift. Different crew, different mix of roles, different judgement calls: the same shift on two nights could produce two different shapes of payout.
03 · Bottleneck
There was no record to point at.
Without a stored calculation per cruise, a question about last weekend could not be answered. It could only be re-argued. That was the real cost: not a line on a P&L, but disputes among staff on a small team where everyone works the same deck next weekend.
04 · Why off-the-shelf did not fit
The fix was not a bigger spreadsheet.
It was making the rule the only thing that decides the number. A spreadsheet still needs a person to remember what was agreed last month and to work it out the same way every time.
Custom software · Palapa Tours Ottawa · Shipped
Software should come from the workflow.
Not the other way around. On a floating tiki-bar cruise the tip-out was worked out by hand after a long shift, and the split moved depending on who did the arithmetic. The fix was not a bigger spreadsheet. It was making the rule the only thing that decides the number.
Small problem. Real operational impact.
Consistent payouts. Transparent logic. A question about last weekend has an answer instead of an argument. The client owns the code.
Read the Palapa study05 · The build
Software that does one job properly.
The cruise closes, the gratuity pool is totalled, the split rules the operator set are applied, and every staff member's payout is written down and kept. The rules are set once instead of being re-decided at the end of each sailing.
06 · AI and automation
No AI. Deterministic arithmetic.
This is a place where AI does not belong. The calculation has to come out the same way every night, so it is software with fixed rules, not a model.
07 · Human role
The operator sets the rules. Once.
Roles and percentages are whatever the operator decides. The software applies them the same way no matter who is looking.
08 · Result
Consistent payouts. Transparent logic. Fewer arguments.
The number is the same number whoever runs it. A question about a past sailing has an answer. No hours or dollar figure is claimed. The engagement is closed, the software shipped, and Palapa owns it.
The interface shown on this site is a diagram, not a screenshot. Role names and percentages are placeholders standing in for whatever rules an operator sets, not Palapa's figures.
09 · What came next
The same idea, at venue scale.
Tip splitting by rules agreed before the shift is also a family inside Fennec, where it sits next to the stock count on the same arithmetic.
Source of every statement on this page · exdsconsulting.com/work-palapa-tours · verified 2026-09-16
Free · 30 minutes · a founder answers
Small problem. Real operational impact.
A narrow workflow that only works because one person remembers the rule is exactly the kind of thing worth thirty minutes.