City Dreams: Turning a property business into a platform.

City Dreams lets and manages short-stay flats in London. I learned the model, built the business around it, and then built its IT: the system of record behind every booking, the channels and pricing integrated around it, and a site of our own where the price a guest sees is the price they pay.

How it came together

Six stages of the classic product cycle, from learning an industry to a live site taking real bookings.

1. 01

   Ideation and screening

   2024Done

   The business has two customers who need opposite things: owners handing over a flat, and guests choosing between identical-looking listings.

   My role

   I learned the model commercially: owner proposals, management fees, and the real costs of running accommodation.

   Decisions

   • Rent-to-rent and managed flats, so that the offer fits what an owner actually wants.
   • Own the guest relationship, because a platform booking belongs to the platform.
   • Two audiences, one business, so that our own flats prove the management offer.

   Outcome

   An operating model I could put in front of owners and stand behind in practice.

   Challenges

   A new industry: every commercial term had to be learned before it could be negotiated.

2. 02

   Product definition and planning

   2024 – 2025Done

   Guests were finding the flats on Booking.com and Airbnb; what the business needed behind them was one system of record.

   My role

   I configured Guesty as the system of record and integrated the channels, dynamic pricing and payments around it.

   Decisions

   • One system of record, because two calendars mean a double booking.
   • Optimised listings on Booking.com and Airbnb, so that demand comes from where guests search.
   • Dynamic pricing integrated, because nightly rates cannot be set by hand.

   Outcome

   A running booking operation: reservations, calendars, rates and payments in one place, across the channels.

   Challenges

   Each channel wants its own fields and photographs, so every listing had to be maintained separately.

3. 03

   Design and prototyping

   September 2026Done

   A site of our own needed a brief (the full price before any interaction, nothing added at checkout) and a brand with more restraint than the 2024 brandbook.

   • 

   • 

   My role

   I wrote the brief and directed the brand: the directions explored, the ground chosen, every page drawn.

   Decisions

   • Full price before any interaction, because the fee at checkout is the complaint.
   • Lime rationed to one element, because it is a light source, not a colour.
   • Headings light and large, so that the geometry reads considered rather than loud.

   Outcome

   A brief specific enough to build from, and a documented system with every page drawn in it.

   Challenges

   Photography is the open item: the reference designs use placeholders where the real rooms belong.

4. 04

   Validation and testing

   September 2026Done

   Money and availability are the two things a booking site cannot get wrong, so both were exercised before anything went live.

   My role

   I ran the checkout end to end and read the brand's own posting data before committing to a direction.

   Decisions

   • Test against real reservations, because a mocked calendar proves nothing.
   • Rehearse the failures, so that a declined card and a mid-checkout reload behave.
   • Let the account's own numbers decide, because the evidence was already there.

   Outcome

   Checkout verified against live reservations in test mode, and photography confirmed as the thing worth spending on.

   Challenges

   No user testing yet: the evidence is one account's posts and my own runs through the booking flow.

5. 05

   Development

   September 2026Done

   Three days from the design spec to a live domain taking real bookings, built with AI assistance and my own quality bar.

   • 

   • 

   My role

   I built it: nineteen pages, ten API routes, and the booking chain through the property and payment systems.

   Decisions

   • A calendar mirror in memory, because pages cannot wait on an API.
   • A real fifteen-minute hold, so that nights block everywhere the moment checkout starts.
   • Confirm only after settlement, because money verified server-side is the only proof.

   Outcome

   Availability from memory, prices from a live quote, and no reservation ever confirmed before payment.

   Challenges

   Holds and the mirror live in memory, so the site still needs one always-on instance.

6. 06

   Launch and commercialisation

   September 2026 – presentIn progress

   The site went live on the domain, the old pages redirected into it, and then the API's daily token quota ran out.

   • 

   My role

   I ran the launch: the migration, the structured data, the incident and the fix that followed it.

   Decisions

   • Degrade by section, not by page, because one outage took the whole site down.
   • Cache the token, so that a day of deploys costs one request.
   • Redirect every old URL, because nothing the old site published should 404.

   Outcome

   A live direct-booking site with its own content, its own checkout and a written deployment runbook.

   Challenges

   Thin residence descriptions and the unshot photography are now the weakest thing, not the code.

What exists today

• 19pages live
• 10API routes
• 3days, spec to live
• ~9,650lines of TypeScript

The business

• Short-let residences in London that we design, furnish and run ourselves.
• Property management for other London owners, offered on the same site.
• Guesty as the system of record, with Booking.com and Airbnb connected and dynamic pricing on top of it.
• Listings maintained per channel: its own photographs, title, amenities and rate plans.
• Guest operations behind every stay: communication, housekeeping, maintenance and the financial administration.

The guest side

• Residence pages with a live quote: nightly rate, cleaning, total, payment schedule and cancellation terms.
• A fifteen-minute hold that blocks the nights everywhere while a guest checks out.
• Nothing added at checkout: the number on the card is the number on the receipt.
• A London guide and an imported journal, so the site holds content of its own.

Under the hood

• A per-night mirror of the channel calendar, warmed at boot, polled and updated by webhooks.
• Reservations created over the hold and confirmed only after payment is verified server-side.
• Listings and calendars written to disk, so a restart serves the last known state.
• Section-level degradation: an outage leaves the photographs and the writing intact.
• Per-page social cards, a live sitemap and structured data for search and answer engines.

Trading business, September 2026. The figures describe the site as built and the business as it runs; occupancy, revenue and portfolio growth are not published here.

Learnings

• When a site is a window onto someone else's API, decide in advance which parts may fail. Ours treated "no listings" as fatal, so a spent token quota took down the guide and the photographs along with the prices.
• The hard part of direct booking is not the form. The same nights are on sale on four platforms at once, and the site must never sell one twice or quote a price that is not real.
• The brand's own numbers settled an argument that taste could not: photographs of real rooms ran about three times the reach of templated graphics on the same account.
• The biggest lever on how the brand reads was not a new typeface but setting the headings light and large. Same geometry, completely different register.
• A listing is marketing, not data entry. Each channel ranks and renders the same flat differently, so the photographs, the title and the amenity set have to be maintained per platform rather than written once.
• Running the business is what makes the product decisions obvious. Every rule the site enforces (the full price, the shared calendar, the hold) is a complaint I had already handled as the operator.