A rental app with zero dependencies, built for my own house.

Context

For four winters I have rented a house on a Canary island and shared it with friends for a few weeks at a time: beds by night, a van split between whoever is around, shared shopping, a cleaning day, a deposit somebody forfeits. The first three seasons ran on a spreadsheet. It added up numbers and answered none of the questions I had.

Problem

Three questions came up every season and none of them was a cell in a sheet:

• Who is sleeping where on which night, with overlaps caught before two people arrive for one bed.
• What does each person owe, when the price depends on how long they stayed, one bed was given away for free and the van cost is shared only among the people who were there that day.
• Will the season break even, given what is booked today and what a realistic worst case looks like.

The spreadsheet answered the second question badly and the other two not at all. Every version I patched together made the next season harder to start.

What I built

A single-file web app. index.html is the whole application and Node's standard library is the whole server. There is no build step and nothing to install.

• Calendar: a bed-by-day grid, one month at a time. Overlapping bookings are flagged. Events sit in a labelled row above the grid.
• Pricing: per night, per bed, with length-of-stay tiers, so the rate follows from how long someone stays instead of being tagged by hand. A per-stay custom price overrides everything, which is where a last-minute discount goes.
• Guests: charges, payments, balance. Charges cover anything beyond lodging.
• Finances and forecast: revenue booked, payments received, costs by bucket, occupancy, season ceiling, break-even. The forecast derives its scenarios from the actual data: a pessimistic case, the break-even point, what is booked, a full house.
• Shared costs split per day among whoever was in the house that night, instead of divided equally at the end. Someone who stays three weeks pays for three weeks.
• Guest access: each guest gets a code and a filtered view with the shared calendar read-only, their own charges and the events they can join. The filtering happens on the server, so other people's balances and the price list never leave it.
• PWA: installable, works offline, phone-first, light and dark themes.

I built it with Claude Code over a few evenings, then cut a public template out of the private version: neutral demo season, house-specific wording generalised, my own financial assumptions removed and turned into settings. The template ships with 467 test assertions covering pricing tiers, the season ceiling, occupancy, forecast, offline behaviour, palette contrast and the guest-view privacy filter.

Result

The current season runs on it. The three questions are answered on one screen each, and the spreadsheet is retired. The template is public under MIT for anyone who runs a shared rental and wants software that fits their house instead of a booking platform built for hotels.

What I would build differently today

Nothing structural. The decision to skip a framework was the point: a person who rents a house should be able to open the file, read it and change the wording without a toolchain. The one thing I would do earlier is the guest view. It changed the tone of the season more than any feature for me, because the questions "how much do I owe" and "is Thursday free" stopped arriving on WhatsApp.