Vacationr

I'm building Vacationr for the holiday home my family shares. One calendar holds our own stays, friends' stays and the platform bookings. A ledger keeps track of who owes the house money, and who the house owes. Every payment goes between a member and the house, never between two of us. It's a work in progress, built for one house.

The spreadsheet

The house is a family chalet in the Alps. Six adults share it, and the chalet has one Swiss bank account. Pay for the winter's firewood and you claim it back from that account. Book a week and you pay into it.

Before Vacationr there was a spreadsheet, which I built in March. Two tabs drew the year as a calendar, coloured by who was staying. A script pulled the Airbnb calendar every six hours and flagged any stay that clashed with it in red. A summary tab worked out what each person's nights cost at the season's rate. Whether anyone had actually paid was a column somebody typed in by hand.

The sheet worked out the costs. People still had to message one person to check availability or get a request approved. They asked the same person whether the firewood had been paid back.

Nothing off the shelf

I looked for something to buy first. Software for holiday homes is made for renting them out, with a host, guests, nightly rates and a payout. We're not a business, and the people staying are mostly the owners. Tools for shared ownership assume shares, a schedule of weeks per owner and a company in the middle. We have none of those. We share a bank account and a calendar. Our cleaner needs to see maintenance issues, like a broken gutter, without seeing the finances.

Members book and pay. Admins approve requests and claims, and mark money received. Helpers see maintenance and the house guide, and nothing financial.

The house account

In the app, the house holds the money. An admin looks after the account. If I treated the admin as holding the money, they'd owe themselves whenever they paid for something.

Members get an invoice for their own stays. Payment is due seven days after the booking is confirmed. They get paid back for what they spend on the house. All payments go between a member and the house.

What the house pays for itself, from insurance to council fees, stays out of everyone's balance. Nobody here holds a share. Splitting those costs between us would turn the app into an accounting system, and that's not the problem the family has.

One transfer

A member settles one balance, what they owe the house minus what it owes them. Say a stay costs CHF 331. They also paid CHF 210 for firewood. So they make one transfer of CHF 121. When the house owes more, it pays them instead. The admin marks the transfer received or paid out, and that closes every line it covers.

A member's Overview subtracts what they paid for firewood from the cost of their stay. It shows the amount to transfer and when it's due. The info icon beside the total opens the quote, line by line.

When a member's lines cancel out, an admin marks CHF 0 received to close them. If a member's balance already covers an invoice, the app marks it as covered rather than overdue. And when two stays are open at once, the Overview leads with the one due soonest and still shows one transfer.

The admin's Overview shows what needs approval and who's overdue. It also shows the month's money in and out, and who's arriving next.

Traceable numbers

I start with the calculations, then the screens. Money is whole centimes everywhere, never a floating-point number, which can pick up rounding errors. A member's balance and the breakdown under it come from the same running total, so the two always match. One test checks every figure the designs show. Others generate 500 ledgers and settle each one to zero. They also check that shuffling the records leaves every balance unchanged. I direct Claude Code to write the code from my specs. I review it, and these tests are how I trust what it wrote.

Each page has one function that turns the house's records into all the text you see. The tests check the text that function produces. I also compared the built Ledger and Overview with their Figma exports. For each difference, I wrote down whether the design or the code was right, and why.¹

For now, I'm testing it with my family before I launch it.

1. Those decisions are recorded in numbered build notes in the repo, alongside the Figma exports. Two architecture decision records explain the money model. The house holds the money, and each member settles one balance. ↩