I described this app out loud. Claude Code wrote it.

Context

Renting a house for a season and sharing it with a rotating group of people is a booking problem that no booking platform fits. Beds go by the night. Everyone arrives and leaves on a different date. Some costs belong to the whole house, like a van, and only the people who were actually there that day should pay for them.

For years this one ran on a spreadsheet, and the spreadsheet worked. It knew what the season had earned and what each person still owed. What it could not do was work without a person driving it.

Problem

Every answer went through one person. Not because the arithmetic was hard, but because the sheet only held numbers, not the rules that produce them.

What the sheet left to a person

• Read the dates and decide which rate applies, because the price depends on how long somebody stays and no cell knows that.
• Work out who slept in the house on each night before a shared cost can be divided, then redo it whenever a booking moves.
• Answer 'what do I owe' and 'is Thursday free' one message at a time, because nobody else can open the file.

None of it is difficult. It is just constant, it happens while everyone else is on holiday, and one wrong line produces a number that is confidently wrong. And none of it can be handed over: the file lives with whoever built it, so every question comes back to the same person.

How I built it

I did not sit down and write this. I described it, and three days later it was running a real season.

I told Claude Code what a season looks like, what each screen should show, and what the rules are: how the rate depends on how long somebody stays, how a shared cost gets divided, what a guest is allowed to see. It wrote the code. I read what came back, said what was wrong, and it changed it. Most of that happened out loud, in the evening, over three days. Improvements have landed since, in ones and twos, whenever something turned out to be missing.

Three days is the part I would not have believed a year ago. Not that an AI can write code, but that describing software carefully is now most of the work of having it.

What it does

One HTML file is the whole application. There is nothing to install and no build step. It opens on the calendar, and the tabs across the top are the season in the order you deal with it.

Full size

This is the view that replaced the sheet's first job: who is sleeping in which bed on which night. A double booking shows up as a conflict before two people arrive for one bed, rather than in the message where one of them asks why somebody is in their room.

Behind the grid, every stay carries its own rate, and the rate follows from the dates.

Full size

That badge is the first piece of judgement the app takes off a person. In a sheet, the tier is something you apply by reading the dates. Here it is a consequence of them.

Once the rates follow the dates, the season adds itself up.

Full size

This is the answer a spreadsheet never really gives. It can total what the season has earned so far. It cannot say what happens if the last three weeks go badly, because that is a model, not a total.

The next tab is the one that used to eat an evening: a shared cost divided among whoever was actually in the house, day by day. Split equally at the end of the week, everyone pays the same and the person who showed up on Thursday subsidises the person who was there all along. Split per day, the arithmetic follows who was actually in the house.

Full size

A spreadsheet can do this. The formulas exist and I wrote them. What changed is that nobody writes them any more: a booking moves, and every share moves with it.

The number nobody expects is the range. The van costs what it costs, so a night in a full house is cheaper per person than a night in a quiet one. Stating that outright settles the argument about whether the quiet weeks were somebody's fault before anyone starts it.

This is also the part that makes it a shared app rather than a private sheet. It is a settle-up tool the whole house can open, so it holds the Splitwise invite and the payment link too, and the pay button only appears to somebody who actually owes something.

1. 01

   Every guest gets their own panel. A code, and then their own page: the shared calendar read-only, what they owe, and the events they can join. This is the feature that changed the season most. Questions stopped arriving as messages, because the answer was already on the asker's phone.

2. 02

   Guests carry charges, payments and a balance. Lodging is only part of it. A share of the van, a shared shop, a forfeited deposit, all against the same person, so one number answers what do I owe.

3. 03

   Events are shared, not announced. A cleaning day, a barbecue, a station pickup. Anyone can add one and see who is going, which is one fewer thing living in a group chat.

4. 04

   It works on a phone, and offline. You can add it to your home screen and it opens like any other app. It keeps working with no signal, which matters when the house wifi does not reach the terrace.

Result

A season runs on it and the spreadsheet is retired. The arithmetic that used to be done by hand now happens when a booking is entered, and the answers reach everyone without passing through one person first.

Then I cut a public template out of the working version: neutral demo season, house-specific wording generalised, the financial assumptions pulled out of the code and turned into settings. Every screenshot on this page is that demo. It is MIT-licensed, for anyone who runs a shared rental and wants software shaped like their property instead of a booking platform built for hotels.

The season is a file, so an agent can run it

One decision turned out to matter more than the rest: the season is stored as a plain file in a git repository, not in a database.

A database would have been the obvious choice, and it would have locked the data behind a login. As a file, the whole season is something an agent can open and edit directly, with no password to hand over and no API to build first. So changing something does not have to mean finding the right screen and filling in a form. You say what should change, and the agent edits the season.

It also means every change is a commit. If a number looks wrong, the history says when it changed and what it was before, which is more than most spreadsheets can answer.

The hard part

The guest view, and not for the reason I expected.

Filtering what a guest sees is easy to do and easy to do wrong. Every quick version does the filtering in the browser: fetch the state, hide the parts that are not yours, render. It looks correct. It is not. Everyone else's balances and the entire price list are sitting in the response, one developer-tools tab away from anyone curious.

Getting it right meant the filter had to live on the server and the guest client had to stop being able to compute prices at all. Every amount a guest sees arrives already calculated. That is not a view change, it is an architecture change: two different shapes of the same state, a narrow set of operations a guest is allowed to perform, and tests that fail if a rate ever appears in a guest payload.

The privacy filter is the smallest feature in the app and it took the longest.

What this actually says

The app is useful, but it is not the interesting part. Plenty of people run a shared house on a spreadsheet and put up with being the person who operates it, because the alternative used to be hiring somebody or learning to code.

That is the bit that changed. I described what I wanted, carefully and out loud, and got working software back. The hard thinking was still mine: how a rate should follow from the dates, what a guest must never see, who pays for the van on a day they were not there. But writing that down in code stopped being the barrier.

Which is why I made it a template rather than keeping it. If you run something small and awkward that a spreadsheet almost fits, the app you actually want is closer than it used to be.