01The situation

Your Porter was a 20-person SaaS for Airbnb hosts managing multiple listings: calendar sync, automated messaging, task routing. As COVID pulled the travel industry into a prolonged slump, company revenue was down roughly 60% from pre-pandemic by that autumn. The CEO and our VP of Product gathered the PMs in a room and asked us to come back with short-horizon, revenue-generating add-ons we could ship fast.

Smart-lock automation was on the shortlist. In the Airbnb hosting context, that means replacing the old key-handover routine at check-in: the host installs a connected door lock on the property, and the software generates a unique access code for each reservation, delivered to the guest before arrival and expired at check-out. No in-person meetup, no lockbox, no spare keys floating around.

The first scoping pass flagged three real constraints:

1. Official vendor APIs (Schlage, Yale) required roughly $5K in minimum commitments, outside the crisis budget.
2. SSL pinning on the vendor mobile apps made API reverse-engineering look impractical.
3. Smart-lock adoption was still largely US-only at the time.

All three were accurate within the framing they assumed. The question was whether the framing itself could be changed.

02Removing the technical blocker

The original scoping assumed the only path was intercepting API traffic between the vendor app and server, which SSL pinning is designed to block. After a week of research, I found a different path. Host the vendor mobile app on a headless Android emulator under our control, drive its login flow with UI automation, and let the pinned handshake complete as the vendor intends. Session tokens are read out of the emulator and handed to our backend, which then calls the vendor APIs server-to-server with a legitimate credential. Pinning never enters the picture.

Total infrastructure footprint for the add-on: one cloud VM, around €30 a month. The findings went into a 30-minute 1:1 with the CEO, who has an engineering background, and we agreed on a cautious green light.

03Validating demand first

Before any build work, I ran a joint email campaign with marketing to the host base. Two questions: which smart-lock brands do you own, and would you spend 20 minutes talking about your current guest check-in flow. Over the following two weeks, I ran 20+ interviews with hosts who replied.

The pattern was consistent. Hosts were actively repositioning their properties as safer during the pandemic. Guests were asking, unprompted, about no-contact check-in. Physical key handoffs had become friction hosts wanted to remove rather than manage. And one commercially relevant signal: hosts were open to passing a small fee on to guests, provided it didn't hurt booking conversion.

The interviews also reframed the US-only adoption concern from Section 01. Multiple EU and AU hosts we spoke to had either just bought a connected lock or were actively shopping for one, pushed by the same pandemic-era guest expectations we were hearing stateside. What had looked like a ceiling looked more like a snapshot of a market that was about to move.

04What shipped

On the surface, a single in-app setting. A host connects a lock account once. From then on, every new reservation automatically receives a unique door code, scoped to expire at check-out. The design effort sat everywhere else.

From the guest's point of view

The product was never framed as a smart-lock integration for hosts. It was framed as a check-in experience for guests. That framing drove most of the decisions that followed.

A code nobody forgets

The access code wasn't random. It was the last four digits of the guest's phone number, valid only for the duration of their stay. Guests could recall it instantly because no one forgets their own phone number. A small design choice that removed a whole class of support tickets before they could form.

Not an integration, an experience

Your Porter already had an automated guest-messaging system that hosts depended on. The lock add-on plugged into it, so the access code arrived a few hours before check-in as part of the flow guests and hosts were already used to. What shipped wasn't framed as a smart-lock integration. It was framed as contactless check-in, an end-to-end experience where the lock happened to be the enabling piece.

Priced to the guest, not the host

Using Airbnb's extras mechanism, the cost was structured as a guest-side charge rather than a host-side cost. That unlocked a premium "contactless home" positioning for hosts to market during the pandemic, while guests saw a small, well-framed surcharge for a service many were already asking for.

05Outcome

By March 2021, six months after launch, the add-on was generating €7K/month in recurring revenue and had become one of the product lines carrying the company through the pandemic. Later in 2021, Your Porter was acquired by Guesty, the industry leader at the time. The add-on line was one of the product stories that came up during the process.

We launched through a closed beta first, with a small group of trusted hosts. I watched support tickets closely and ran follow-up interviews whenever issues surfaced. The emulator setup depended on things outside our control: vendor UI updates, vendor-side outages, the occasional token-refresh edge case. Keeping that feedback loop tight was how we stayed credible.

Post-acquisition, with Guesty's budget available, we migrated off the RPA setup onto official vendor APIs, extended the feature beyond Airbnb, and folded it into the broader Guesty surface. The €30 emulator VM was retired. With access to official APIs and a wider platform footprint, the add-on crossed €15K/month in recurring revenue.