Booking was solved. Deciding wasn't.

In short: our research showed that for group travellers, booking a hotel was easy; agreeing on one was the hard part. I led product and delivery for StayNow from an idea to a six-product platform, built around Trips, a shared space where a group can shortlist, discuss, vote on and book a hotel together. 80% of beta users used Trips, and Trips invites became a major source of new sign-ups. After public launch, StayNow grew to more than 2,000 sign-ups a month. It launched with more than 10,000 bookable hotels, and after I restructured the team into pods, it delivered 25% more per sprint.

Why would anyone leave Booking.com?

When I joined in November 2022, StayNow was an idea: a booking platform for independent hotels in the US and Canada, aimed at millennials and young people travelling in groups. The founders had a strong network of hotels. What they didn’t have yet was an answer to a simple question: why would anyone leave Booking.com?

So we started with research. Over three months, our UX team and I interviewed 100–120 people, then another 80 once we had early versions to show them. The mix was roughly 55% women and 45% men, aged 18 to 55. Most were millennials and leisure travellers, with a meaningful group of business travellers.

One pattern stood out. Booking a hotel was not the problem. Every platform does that, and does it about the same way. The problem came before booking: choosing the hotel that fits the plan. Big platforms were built one-size-fits-all. They didn’t plan around individual preferences, and they had nothing for groups.

And group leisure travellers struggled the most.

The hero feature: Trips

I recognised the problem from my own trips. Planning a group holiday meant juggling five tools at once: a spreadsheet of options, a WhatsApp or iMessage group arguing about them, a Pinterest board of hotels someone liked, shared notes, and endless Google searches and travel vlogs. By the time the group agreed, the room was often gone.

Research confirmed it wasn’t just my circle. So we designed our hero feature around how groups already behave in chats, and put everything in one place. We called it Trips:

Wishlist: a shared board, like Pinterest, where anyone can pin hotels and mention friends.
Chat with voting: discuss the options and vote on them right in the conversation.
Book in the same place: the decision and the booking happen together, before the room sells out.
Split payments came later, once we saw that paying as a group was its own bottleneck.

It worked. In the closed beta, 80% of users used Trips, and because a Trip only works when your friends join, every Trip was also an invitation. Trips invites became one of our biggest sources of new sign-ups. The hero feature was also the growth engine. The most requested additions were reactions in chat and group calls, both built after I moved on.

The launch baseline: five products at pre-seed

Most pre-seed startups ship one app. To reach parity with what travellers and hotels already expected, we needed five from the start:

Traveller web app
iOS app
Android app
Hotel-manager portal, where hotels manage rooms, rates and bookings
Super-admin portal for the StayNow team

That’s a heavy build for a pre-seed company, and I’ll come back to its cost at the end. What kept it manageable was phasing: each product launched with a core feature set, and the rest arrived in later releases, so no single product held up a release.

My proposal: hotel-branded booking sites

In February 2024, shortly before public launch, I proposed a sixth product as a new revenue stream.

My research showed a gap on the hotel side. Direct bookings through a hotel’s own website brought in only 8–10% of an independent hotel’s revenue, and those websites, usually run by third parties, offered a poor booking experience. Independent hotels wanted more direct bookings but had no good way to get them.

We already had everything needed to fix that: inventory, rates, payments and a booking flow. So I proposed hotel-branded booking sites: a website for each hotel, on the hotel’s own domain, running on StayNow’s platform. Hotels paid a fixed subscription, and StayNow took no commission on their direct bookings. That’s the opposite of how booking platforms usually earn, and it was exactly what hotels wanted: every direct booking stayed theirs.

Solving the empty-marketplace problem

Every two-sided marketplace starts with the same trap: no hotels means no travellers, and no travellers means no hotels.

The founders’ hotel network gave us a head start, but not enough to feel like a real alternative. So the founders decided to integrate a channel manager, the software hotels already use to publish rooms and rates across booking sites. Delivering it was one of the hardest parts of the build, but it meant more than 10,000 hotels were bookable from launch.

That changed the conversation with hotels. Once they saw real travellers using StayNow and leaving good feedback, more of them wanted to connect directly. We then integrated with their property management systems (PMS), so they could run StayNow without managing yet another platform.

What we killed: 3D room previews

Not every idea survived. We were excited about 3D room previews, letting travellers walk through a room before booking. We built designs and product prototypes.

Then we asked hotels. They weren’t ready to capture and edit 3D scans of their rooms. It was real work for them, with no clear payoff. Without that content, the feature was an empty frame.

So we killed it.

It taught me the rule that runs through this whole project: on the hotel side, anything that asks hotels to do extra work stalls, and anything that removes work from them succeeds. The channel manager, PMS integrations and branded booking sites all worked because they saved hotels effort or brought them revenue without extra work. 3D previews asked for more.

Shipping 25% faster with pods

Six products and a 15-person team meant constant contention. In the first phase, everyone worked in one shared sprint, so work on one product often waited on another.

In early 2024 I restructured the team into pods: small, independent teams, each owning its own products, working in parallel. I reworked the sprint structure to match.

We measured the result in story points per sprint, comparing January–June 2024 with April–December 2023: the team delivered 25% more per sprint. The release cadence stayed the same, so every release carried more features, and the roadmap moved noticeably faster.

Launch

Development started in April 2023. The first version went live as a closed beta in August 2023, and from August to October it brought in about 1,500 sign-ups. They came from on-the-ground marketing inside partner hotels, SEO, digital campaigns including paid ads, and, increasingly, Trips invites. StayNow launched publicly in March 2024, 15 months after research began. After launch, sign-ups passed 2,000 a month and kept rising as marketing scaled up.

Where it landed

From idea to a six-product platform: closed beta 9 months after I joined, public launch 15 months after research began
Research with ~200 people across two phases
10,000+ hotels bookable from launch, followed by direct PMS integrations
~1,500 sign-ups in a 3-month closed beta, then 2,000+ a month after public launch
80% of beta users used Trips, and Trips invites became a major sign-up source
A second revenue stream: branded direct-booking sites for hotels on a fixed subscription, with no commission
25% more delivered per sprint after moving to pods

StayNow is live at staynow.com (opens in new tab). I moved to another client project in August 2024.

What I’d do differently

Go to market sooner, with bare-bones booking. We waited until the whole suite was ready. In the meantime, the market caught up: competitors shipped similar group and planning features, and some of our lead was gone before launch. A simple booking product in travellers’ hands months earlier would have given us real usage data sooner, and a head start that competitors couldn’t copy overnight.

That’s the cost of the launch baseline I described above. Parity mattered, but I’d now test the core idea with the smallest product that can take a booking, and add the rest once people are using it.