Why the Trip Ends Before the Settling Does

After a long Asia trip, I had a mess of expenses spread across four currencies, tracked across a WhatsApp thread, a few voice notes I'd sent myself, and the part of my memory that was nominally in charge of keeping rough count.

Nobody disputed what anyone had spent. The problem was that everything I would need to actually settle it had to be reconstructed from scratch. Every time we talked about it, someone would go quiet and start scrolling back through their banking app. Then we'd lose the thread.

I kept thinking: the maths is not hard. Four people, fifty-odd expenses, a bit of currency conversion. You could solve this in a spreadsheet in an afternoon.

But nobody does. Because nobody wants to build the spreadsheet.

That's the actual gap. Not that the calculation is complicated. That the context disappears before anyone gets around to doing it.

Why I built this instead of just using Splitwise

Splitwise exists. Tricount exists. There are good tools for this.

I built it into Finance Watchtower anyway, for a specific reason.

The rest of the product is already about this kind of problem: situations where the work to get clarity is technically doable, but just high enough effort that most people defer it indefinitely. The car insurance tool, the housing decision model — same shape. You're not missing information. You're missing a clean place to work through it without starting from scratch every time.

Group expense settlement fits. It's not complicated. It's just annoying enough that it keeps getting put off until the trip feels ancient and nobody can be bothered.

The most interesting decision: how do you present the result?

My first instinct was to show all the pairwise balances. Full transparency — every person, every directional debt. Ten transfers for five people.

Technically correct.

Also completely impractical. Nobody is going to organise ten individual bank transfers after a group trip. What usually happens instead is someone tries to simplify it in their head, gets confused, and the whole thing quietly stalls for another week.

So the tool does two things. It runs a debt simplification pass — the largest debtor pays the largest creditor, repeat until done. Ten pairwise balances become three or four actual payments. And it shows both views: the simplified default, and all the individual transfers if someone wants to check the working.

The "10 transfers → 3 payments" label is there deliberately. I wanted the group to see what got collapsed, not just receive the answer. Most people will take the three payments and move on. Some will want to verify. Both groups need something.

That's the trust mechanic.

Why the audit trail isn't a nice-to-have

There's a button in the reimbursement view called "Show calculations." It opens a full breakdown: every expense, who paid, who owed what per item, how each person's net balance built up.

I thought about leaving this for a later version. In the end I didn't, because without it the result is hard to act on.

When someone owes more than they expected, the first instinct is to question the number. If the tool can't show its working, that question becomes a conversation nobody particularly wants to have. The audit trail means the answer is already in the product. "Here's every expense. Here's your share of each one. Here's how that adds up."

That's what makes settlement feel fair rather than contested.

Multi-currency: in scope, but kept manual

I was tempted to defer multi-currency support.

The Asia trip had four currencies. Deferring would have made the tool useless for the exact event that motivated it, so I kept it in. The tradeoff was keeping it manual: you set one exchange rate per currency for the event, and the tool applies it consistently across all expenses.

Fetching live historical rates introduces API dependencies, rate freshness questions, and decisions about which date to use for each expense. None of that felt worth it in the first version. The manual approach is simpler and honest about what it is. There's a disclaimer in the reimbursement view: "Exchange rates are estimates. Final transfers should account for bank fees and actual rates at time of payment."

One rate per currency, set once. Good enough for a group trip where the numbers roughly make sense. Not a foreign exchange service.

What I deliberately left out

• Account linking — participants are names only, not Finance Watchtower accounts
• Automatic exchange rates — manual only, for the reasons above
• Push to transactions — the schema has a nullable foreign key for a future link, but the action doesn't exist yet
• PDF or CSV export
• Notifications or reminders

The filter I kept coming back to: what's the smallest version that produces a result the group will actually settle on?

Once the answer to that was clearly yes, I stopped adding things.

It was built in an evening

The design work had happened the day before — data model, algorithm, UX flows, edge cases, multi-currency mechanics. By the time I sat down to build, the decisions were already made. Claude Code helped move through the implementation quickly once the spec was clear.

That's the part worth noting. The technical problem of building a group expense calculator is not especially hard. What takes time is figuring out what to include, what to skip, and how to present results in a way a group of people will actually act on.

Getting that right first is what made building it fast.

The version that shipped is not the most capable group expense tool available. It's just the most useful version for someone already using Finance Watchtower who wants to close out a trip without fighting about a spreadsheet.