Vibecode build plans · № 5

Build an expense splitter

One trip, one file, no accounts — a plan you can paste into your agent, with the money math traps marked.

A bill splitter is a deceptively good vibecode. The interface is trivial — a list of who paid what — but the moment you press "settle up," you are doing the one thing software is supposed to be good at and people are famously bad at: making the numbers actually balance. That's where the build earns its keep, and where an unsupervised agent will quietly get it wrong.

This plan is opinionated. It steers your agent away from the failure modes that make a splitter feel authoritative while being subtly incorrect — floating-point cents, transfers that multiply, the dropped remainder that leaves someone owing a phantom penny — and toward the thing that matters when real money is on the line: a settle-up your friends will trust.

The spec — and the cuts

• One HTML file. Inline CSS, no build step, no framework, under 50KB. localStorage holds the current group so a refresh doesn't wipe the dinner.
• One group at a time. Add people, add expenses (who paid, how much, who it's for), see who owes whom. That's the whole app.
• Cut: accounts and login — the group lives in this browser, shared by a link or a screenshot, not an auth system.
• Cut: history of past trips, currency conversion, and notifications. One trip, one currency, no server to push from. If you outgrow this file, you'll know.

The prompts

Tick the features you want — the prompts below rewrite themselves. Then paste them into Claude Code (or Cursor, or any agent) one at a time, in order.

Where agents go wrong on this build

• Floating-point money. Left alone, an agent will store dollars as 19.99 and add them up — and 0.1 + 0.2 is not 0.3 in JavaScript. Every amount must live as an integer number of cents; format to dollars only at the moment of display. A splitter that's off by a cent is a splitter no one trusts.
• N² transfers. The naive settle-up has everyone who owes pay everyone they owe — for eight people that's dozens of tiny Venmos. The correct output is a greedy minimum-transactions settle: net each person to a single balance, then repeatedly match the biggest debtor to the biggest creditor. Four people should almost never need more than three transfers.
• The dropped remainder. Split $10.00 three ways and you get 333, 333, 333 cents — one cent short of the total. If the agent rounds and moves on, the books don't balance. Assign the leftover cent(s) deterministically (e.g. to the first payers in order) so every expense sums to exactly what was paid. Never Math.round and hope.
• Who's actually in the split. "Pizza, $40, for everyone" and "cocktails, $60, for the three of us who drank" are different math. If the agent assumes every expense is split among the whole group, the totals silently go wrong. Every expense needs an explicit participant list, and the per-person share is computed against that list — not the group.

Why the feedback step is in the plan

Money math is exactly the thing you can't see clearly on your own screen. You know what you meant each expense to mean, so you'll read the totals as correct even when the participant list is wrong or a cent went missing. The people who'll catch it are the ones being asked to pay. Prompt 4 wires your agent to our MCP server: it shares the live page, you send the link to one or two people in the group, they tap and pin notes right on the number that looks off (no login), and your agent reads the notes back and fixes what survives your judgment. Better a friend flags the bad split than the group chat does.