Twin City is a home swapping platform that lets creatives exchange homes

across 50 cities through searching, requesting and chatting.

Co-founder, Product Designer

Sep - Nov 2025

1 Engineer

SHIPPED

Redesigned requesting to help users complete their first home swap

I co-founded Twin City. We quickly gained 3,000 users across 50 cities, but most had never actually completed a home swap. This case study explores how providing users with clarity on compatible travel plans helped them experience the magic of home swapping and convert 30% into paying subscribers.

The New Experience

OVERVIEW

We launched Twin City with the basics

Users could browse homes they'd love to stay in and also chat with hosts. The niche of creatives and the selection of designed homes set the platform apart. But the experience? Frustrating…

The Old Experience

CHALLENGE

I needed to understand
why swaps weren't happening

As a member of the community with a home in London to swap, I felt the frustration myself. Requesting was effortful - 6 clicks, write a message, send, wait. But it was exciting when a handful responded, until we ended up in back and forth date negotiation that didn't go anywhere.

Giovanna

24 Jan 2025

Hey Giovanna! I'm planning a trip to Berlin on Aug 1-7.
Free to swap? X

Hi Isaac, I'm keen but am only free the last two

weeks of August.. Would that work?

Ahh it doesn't, I need to be home then :(
What about September 10 - 17?

Conversations were dying at date negotiation

RESEARCH

The root of the problem
was availability, not trust

Many experts advised adding trust features, but when I spoke with 8 users, trust was barely mentioned. The pattern was clear: users logged in with trips planned, but availability only showed vague months like 'August'. The system wasn't matching on dates — it left that to the conversation

"This person looks available in August

but when I propose my dates they're not free."

USABILITY TESTING

Test, learn, refine…

To help users complete swaps, I explored making availability specific and requesting effortless. I tested my approaches with 6 users and ran into a few problems.

Exploration 1: any dates, automated message

BEFORE

The receiving experience was still broken

Users could request any dates with an automated message. Quick for requesters — but hosts barely responded. Dates didn't match, messages felt impersonal.

Exploration 2: confirmed dates, personal note

AFTER

So I connected the
two problems

Requests could only be made from confirmed availability. Users wrote their own messages. Dates already aligned, and messages felt genuine.

SOLUTION

Date alignment happens before conversation starts

Hosts set their availability. Guests find matches for their dates. The system aligns on intent and compatibility.

  1. For hosts: Adding availability

Hosts add precise availability windows that accurately communicate their travel plans. No more mismatched requests.

Adding Availability

II. For guests: Requesting from confirmed dates

Guests see who's available for their trip. They write a personal message and send confident requests quickly.

Sending a request

IMPACT

50% of users subscribed after their first swap

I pushed for a first swap free model to prove value before asking for money. After completing a swap, users' mindset shifted: "I'm doing this all the time now." And the subscription became a no-brainer. Whilst Twin City wasn't skyrocketing, we had 40+ annual subscribers within a few months - enough recurring revenue to reopen conversations with investors.

60+

Swaps booked

Within 3 months of launch.

40+

Annual subscribers

£5,960 in annual recurring revenue.

2x

Request Volume

Average requests per trip: 2 4

REFLECTIONS

Start with the wrong assumption

I assumed trust was the blocker and nearly built verification features. Testing with 8 users proved it was availability. This project taught me to validate hunches early — even the obvious ones — before committing to a solution.

Build less to ship faster

Four weeks and one engineer forced me to design a minimal solution that could solve the problem. This constraint helped us ship quickly and get feedback with users asap.