My wife and I own two flats on the Costa de la Luz in south-west Spain. One is a holiday let on Airbnb and Booking.com, the other is let long-term. We manage them from the UK, and the problem was never complicated, just manual: no shared calendar across the two platforms, prices set by rough guess, and no real view of whether the holiday let was worth the hassle compared with letting it long-term too.
CasaVista is the app I built to sort that out, in March and April 2026, either side of leaving the NHS. It’s a single HTML file in plain JavaScript, no framework. I’d never written a line of HTML, CSS or JavaScript before.
The brief that didn’t survive
I wrote a proper project brief first. It called for a no-code tool, something like Notion, Airtable, or Glide on top of Google Sheets. None of those got used. A week later I set up a Claude Project with the role “Technical Co-founder”: help me build a working app, and teach me to think like a developer while doing it. A spreadsheet dashboard would have met the brief faster, but it wouldn’t have taught me anything, and that was half the point. I was doing a vibe-coding course at the same time, so the app became the practice project as well as the deliverable.
Research before code
Before any interface existed I asked Claude for a briefing on the local holiday-let market: demand, seasonality, and the 2026 calendar of events that move prices, like Semana Santa, MotoGP at Jerez and the local ferias. The market turned out to be overwhelmingly Spanish domestic, roughly 90/10, and extremely seasonal. Every pricing rule in the app traces back to that document, so nothing in the calendar was made up on the fly.
What got built
Four tabs, one at a time, over a handful of build sessions.
- Calendar and pricing. Claude put up three layout concepts. I liked the dark, data-dense one. My wife, who’d actually be using it, liked the warm Airbnb-style one. We used hers as the look and put the analytical detail one tab away. The part I’m proudest of is the recommendation engine: an eight-rule decision tree (August never discounted, event multipliers, lead-time discounts, filling awkward one-to-three-night gaps, weekend premiums) that explains its suggested price in plain English rather than just giving a number.
- Income and costs. The mockup shipped with made-up income figures to make the profit and loss view look meaningful. I asked where they came from, didn’t like the answer, and took them out. Costs stayed real; income shows zero until a real booking is entered.
- Analytics and reports. Built on the same day. Forecasts stay on Analytics and off the profit and loss view, and reports print cleanly to PDF rather than pulling in a library to make Word documents.
Bugs that were data, not logic
One booking kept merging with the one after it. It looked like a bug in the lookup code, but the code was fine. We discovered the test bookings contradicted each other. Real bookings coming in from the platforms shouldn’t do that in theory, but it prompted building in a “double booking flag”.
Where it stands
The mockup reached version 7 with all four tabs built. We then went through four years of my wife’s own spreadsheets, which corrected a couple of my assumptions about what the numbers meant. It also showed up a gap I hadn’t thought about: the calendar feeds from Airbnb and Booking.com give you dates and a platform, never a price, so someone still has to type in what each booking actually paid.
The original plan was Google Drive and Sheets as the data layer. That ran into access problems, so the app now runs self-hosted on my home server instead. The first real decision it fed into was whether to take a three-month let in spring rather than holiday bookings, using the reconciled history to compare the two.