The first version of Staykey's guest experience had an app. A small, purpose-built app, but an app.
It died in beta.
Not because the app was bad — it worked fine — but because we were asking guests to install something for a four-night stay. On vacation. In a market where half of them hadn't heard of us. The conversion rate from "booking confirmed" to "app installed" hovered around sixteen percent. The rest of the guests were still texting us for the door code.
So we threw it out and rebuilt around a single constraint: the guest experience should work at a link, and nothing more.
What "one link" actually means
When a booking gets created in Staykey, we generate one URL for that specific stay. That URL is a live, permission-scoped view of everything the guest needs:
- The access code, visible during the stay window
- Unlock / lock buttons that only work when they're physically at the property
- Wi-Fi details
- Check-in and check-out instructions, parking, trash day
- The local guide, weather, and house rules
The link goes live as soon as the booking syncs and stays live for about two weeks on either side of the stay. Check-in details, local guide, weather, and house rules are visible the whole time; the access code and any smart-device controls only show up during the stay window itself. Guests don't need to time anything — they open the link, and the page shows whatever is appropriate for right now.
The guest gets the link in their booking confirmation, clicks it, bookmarks it (or doesn't — it's in their Airbnb inbox anyway), and uses it for the entire stay. No app, no account, no password.
The host gets the same link preview and can test it before sending. If the guest has questions, support can look at the exact same link the guest is seeing.
The constraints forced better design
Committing to "no app" made the design problem harder in a useful way. A few things we had to get right:
State has to be live, not cached. When the host changes the check-in time, the link updates instantly. When we rotate the access code, the link shows the new one. The URL stays the same; the content is always current.
Access has to be scoped. The link's more sensitive bits — the access code, unlock button, smart-device controls — only appear during the stay window, and the unlock button additionally requires the guest's phone to be within a reasonable distance of the property. The rest of the page (check-in details, local guide, house rules) stays available through the two-week buffer so late arrivals and early planners both work. After the buffer expires the link retires gracefully.
The page has to be fast. Guests are often on bad Wi-Fi at a property they just arrived at, tired, with a suitcase in the other hand. We target under 1.5 seconds to first paint on a 4G connection and measure it every deploy.
No login friction, but still secure. The URL is unguessable and expires on checkout. It's scoped to one stay. We don't need a login flow because the link is the auth.
What changed for hosts
The unexpected win was what "one link" did for host support load. Because the link is the product, hosts stopped getting 11pm texts asking for the code. The number dropped so far that a handful of ProHost customers told us they'd forgotten what the pre-Staykey support load even felt like.
Hosts also started using the link preview as a sanity check before each stay — open it, see exactly what the guest is going to see, confirm nothing's off. That habit caught a lot of "wrong Wi-Fi password" situations before guests ever arrived.
The lesson we kept
Every subsequent feature has faced the same question: can we do this without making the guest install anything? So far the answer has been yes, and the product has been better for the constraint.
If you want to see what the guest actually experiences, we keep a live demo on the /guest-portal page — interact with it, watch the state update, check it on your phone. That demo is the real component we ship, running on real state. Same thing we'd give your guest.
And if you're rebuilding something customer-facing, consider saying no to the app for a while. You might be surprised what you can do at a URL.
Related reading
- Product: Guest Experience — the live demo and the full marketing case for the one-link portal.
- Post: Why Staykey doesn't text your guests — the companion piece on why we keep the one link inside the booking platform's message thread instead of SMS-ing guests directly.
- Guide: How to send check-in instructions that actually get read — the 3-message cadence that wraps the one link.
- Help: Creating your first guest link — set one up for your own property in a few minutes.
- Help: Automating guest links in Airbnb messages — let Airbnb send the link on every booking without you touching it.