Product case study / MatchRoom

We started with the match. We found trust.

MatchRoom is an app for finding a room or a home to rent. Tenants and hosts choose each other, and a conversation opens only when the interest is mutual. Three of us started it in January 2026 as a matching app. Along the way we realised the problem is not only finding the right listing: it is being able to trust whoever is on the other side.

My contribution
App development, technical choices, product and release
Team
Alberto, Andrea and me
Shape
Expo app for iOS and Android, Supabase backend, ranking service, Next.js site
Status
On the App Store in Italy · Android soon
01

Where we started

People looking for a room write to dozens of listings and hear back from few. Often they find out only at the viewing that price, habits or timing do not match. People renting, on the other side, get plenty of messages and have to weigh them one by one. Part of the market runs through Facebook groups and WhatsApp, where contacts are many and trust is hard to judge.

The first idea was simple: not just another catalogue of listings, but help people find a flat, a landlord and, when needed, compatible flatmates. A mutual match looked like a good way to cut useless contacts: fewer conversations, each with a few more reasons to start.

02

Who did what

There were three of us, with fairly distinct jobs.

Alberto held the project together and took it to people. He introduced MatchRoom in hundreds of groups and wrote around a hundred articles on house hunting, with help from Claude Code. Traffic, content and distribution went almost entirely through him.

Andrea worked on the data side: the matching logic, the ranking service, the database structure and the quality of the information matching relies on.

I built the application: mobile app, backend and site, and with them the technical choices, the user experience, the release and part of the branding. I was also the technical point of contact towards the outside.

03

The first MVP

The first commit is from 19 January 2026. Within about ten weeks the app had a complete skeleton: onboarding for tenants, hosts or both, properties and rooms, a deck of cards to swipe, matches and real-time chat.

I picked tools that let one person move fast: Expo and React Native for a single codebase on iOS and Android, Supabase for database, auth, files and real time without running servers.

That speed had a cost I did not see clearly at the time. There were no automated tests, an email verification check had been left switched off, and database permissions trusted too much of what the app sent. The product looked almost ready. The work that was missing turned out to be the longest part.

04

What users told us

Before spending on ads and a launch, we wanted to listen. Alberto drove traffic to a landing page with a questionnaire. I built it with separate paths for people looking and people renting, and by July it was on its sixth version.

The answers showed at least two different ways of looking for a home.

The first group was mostly students and young people looking for a shared place. For them, automatic matching, compatibility between people and finding the right flatmates mattered.

The second group preferred to search on their own. Reviews, transparency, value for money, reliable listings and speed mattered more.

That is where we changed how we looked at MatchRoom. “Tinder for rooms” described the first group well, and not the second. What both had in common was the need to trust.

05

What MatchRoom should become

The questionnaire left us with a product question more than a technical one. We discussed three directions. None of them is final: they are how we think about the app's future today.

  1. A matching app

    Swipes, mutual match and chat, centred on compatibility between people.

    It works for people looking to share a home, but leaves out those who just want a reliable listing, fast. On its own it also risks being mistaken for a dating app.

    It is today's foundation, but not enough.

  2. A portal with reviews

    Freely browsable listings, enriched with reviews and quality information.

    It answers the second group, but puts us head to head with much bigger portals and gives up what makes MatchRoom different.

    Useful as a component, not as the product.

  3. A trust layer on house hunting

    Matching between people and listings and between flatmates, adding over time reviews, verification of listings and landlords, and tools that make the process faster and more transparent.

    Much more work, and parts such as verification or a possible reliability score touch delicate legal ground, to approach carefully and with people who know more than we do.

    The direction we are moving in, one step at a time.

06

An app is not yet a product

At some point we tried to ask ourselves, honestly, what was missing before MatchRoom could be put in strangers' hands. The answer was longer than I hoped, and only partly about code.

We lacked a GDPR-grade privacy policy and terms, a way to moderate photos and text, account deletion that had actually been verified, tester management and the whole store publishing path. We also lacked things no repository solves: how to split responsibilities between us, and who owns the intellectual property of what we were building. Even the first organisational documents we had gathered were not enough once read carefully.

On the technical side I worked on what I could close. In late August a check against Apple's and Google's criteria found sixteen blocking issues. Some were serious, like database functions that accepted another user's identity, or images published without any check. Most were fixed in the following days.

Then came notifications for matches and messages, a moderation console with permissions enforced in the database, account deletion tested all the way through and, for Alberto's articles, a transparency note on the use of AI naming who reviews them.

07

Where we are today

MatchRoom is available on the App Store in Italy. Android will follow after the closed testing period Google Play requires of new developer accounts.

The company has not been incorporated yet. For the first period the app stays free: before deciding how to sustain it, we want to see whether it can bring enough people together, starting from one city.

There is still a lot to learn, and most of it we will learn from users.

08

What I would do differently

I would have asked earlier what it takes to publish, not only what it takes to work. Several audit findings came from choices made in the first weeks, when they would have been cheap to fix.

I would have talked to users before building some parts, like the subscription system we later removed.

I would have written down roles, responsibilities and intellectual property sooner. It is not a technical matter, but it weighs on everything else.

I would have written the first tests against the database, where the worst defects were, before the interface.

Working on an app and wondering what it needs to ship?

I am glad to bring what I learned with MatchRoom to other projects: working out what stands between a prototype and a publishable app, from the code to privacy, moderation and release.

hello@robertodrago.dev