Twin City is a
Twin City is a
home swapping
home swapping
web app exclusively for
web app
exclusively for
web app exclusively for
creatives.
creatives.
Aug - Oct 2025
1 Engineer
Co-founder, Product Designer
The platform connects 3,000+ creatives across 50 cities.
By swapping homes, they explore the world without accommodation costs.
The platform connects 3,000+ creatives across 50 cities. By swapping homes, they explore the world without accommodation costs.
New York
London
Amsterdam
SHIPPED
Redesigned the requesting
flow that tripled bookings
The new experience
Twin City had 3,000 users, but most had never completed a booking.
I redesigned the requesting flow to make availability clear and requests personal.
The impact → bookings tripled and 50% of users converted to paying subscribers
after their first booking.
SHIPPED
Redesigned the requesting flow that tripled bookings
The new experience
Twin City had 3,000 users, but most had never completed a booking. I redesigned the requesting flow to make availability clear and requests personal. The impact → bookings tripled and 50% of users converted to paying subscribers after their first booking.
SHIPPED
Redesigned the requesting
flow that tripled bookings
The new experience
Twin City had 3,000 users, but most had never completed a booking.
I redesigned the requesting flow to make availability clear and requests personal.
The impact → bookings tripled and 50% of users converted to paying subscribers
after their first booking.
OVERVIEW
Twin City was launched
with the basics
Twin City was launched with the basics
The old experience
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? It was a little frustrating…
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? It was a little frustrating…
CHALLENGE
But why were bookings
not happening?
But why were
bookings not happening?
Conversations were dying at date negotiation
Conversations were dying at date negotiation
Giovanna
24 Jan 2025
Hey Giovanna! I'm planning a trip to Berlin on Aug 1-7.
Free to swap? X
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?
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?
Ahh it doesn't, I need to be home then :( What about September 10 - 17?
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.
RESEARCH
The root of the problem
was availability, not trust
The root of the problem was availability, not trust
Old profiles showed "Available in August" giving
users hope but no actual dates to match on
Old profiles showed "Available in August" giving users hope but no actual dates to match on
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 helping users find people with date compatibility, it left that to the conversation.
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 helping users find people with date compatibility, it left that to the conversation.
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.
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: request any dates with an 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 1: request any dates with
an 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 1: request any dates with an 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: request from host's calendar confirmed dates + personal note
Exploration 2: request from host's calendar
confirmed dates + personal note
AFTER
So I connected the
two problems
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.
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
Date alignment happens before
conversation starts
Hosts set their availability.
Guests find matches for their dates.
The system aligns on intent and compatibility.
For hosts: Adding availability
For hosts: Adding availability
Hosts add precise availability windows that accurately communicate their travel plans.
No more mismatched requests.
Hosts add precise availability windows that accurately communicate their travel plans. No more mismatched requests.
II. For guests: Requesting from hosts calendar
For guests: Requesting from hosts calendar
Guests see who's available for their trip.
They write a personal message and send confident requests quickly.
Guests see who's available for their trip.
They write a personal message and send confident requests quickly.
IMPACT
50% of users subscribed
after their first booking
50% of users subscribed
after their first booking
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
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 quite skyrocketing, we had 40+ annual subscribers within a few months - enough recurring revenue to reopen conversations with investors.
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 quite skyrocketing, we had 40+ annual subscribers within a few months - enough recurring revenue to reopen conversations with investors.
REFLECTIONS
Don't trust assumptions
I assumed trust was the blocker and nearly built verification features. After speaking with users, I realised availability was the real issue. That experience taught me to stay neutral about assumptions and validate them early, even the obvious ones before committing to a solution.
II. Build less to ship faster
With only eight weeks and one engineer, I had to focus on minimal solutions that addressed the core problem. The constraint pushed us to ship quickly and gather feedback early, which proved valuable as our initial designs needed several iterations before they worked well. Without shipping early, it would have taken us a lot longer to reach the right solution.
With only a couple of months and one engineer, I had to focus on minimal solutions that addressed the core problem. The constraint pushed us to ship quickly and gather feedback early, which proved valuable as our initial designs needed several iterations before they worked well. Without shipping early, it would have taken us a lot longer to reach the right solution.