The three bookings we almost got wrong

Two weeks before launch, our support lead Sarah sent me a Slack message with a screenshot of a renter's request. They'd tried to book their fourth studio space that month and hit a wall. The message was polite, but the frustration was clear. That's when I realised we'd made an assumption we'd never actually tested with real people.

Why we capped it at all

The logic made sense at the time. Three booking requests per month felt like a reasonable gate for our free tier. It forced a bit of intentionality. It meant people couldn't spam hosts with low-quality inquiries. And it created a clean reason for people to upgrade to Plus, which unlocks AI search and advanced filters that help you find the right space faster.

But we built that number in a spreadsheet, not by watching how people actually use Findr. We guessed. And guessing in a two-sided marketplace is risky because you're not just tuning a product feature; you're deciding whether someone gets to do their work.

The renter in Sarah's screenshot was a photographer. They'd booked three studios already, but none of them had the specific light they needed for an afternoon session. They wanted to request a fourth. That's not spam. That's just how you find the right creative space sometimes.

What launch week actually taught us

We went live with the three-booking cap intact. Within days, our in-app messaging filled up. Not with technical complaints. With conversations between renters and hosts about whether they could make something work. Real negotiation. Real community starting to form.

But we also saw the pattern Sarah had flagged. Creative people often need to scout multiple spaces before they commit. A photographer might need somewhere with north-facing windows. A choreographer might need a sprung floor and mirrors. An event organiser booking for a client might need to see three different room layouts before deciding.

The cap wasn't preventing spam. It was just... happening. Some people hit it and upgraded. Others gave up and went elsewhere. We had no way to tell which problem was bigger because we were too early in our growth to see the numbers clearly. What we could see was the friction in the conversations.

The assumption we were protecting

Looking back, the three-booking cap was really protecting something else. It was protecting our hosts from too many low-quality requests. We thought free users = low commitment = low-quality inquiries.

That turned out to be backwards. The free tier isn't free because the user doesn't care. They're on the free tier because they're a student, a freelancer, or someone trying something new. Those people are actually incredibly thoughtful about their space choices. They've usually been searching for a while. They know what they need.

Our hosts seemed to understand this faster than we did. The messages I saw in the app weren't complaints about low-quality requests. They were actual conversations. Hosts working with renters to find solutions. That's the opposite of spam.

What we're thinking about now

We haven't changed the cap yet. But we're watching it closely. The reason isn't stubbornness; it's that we want to change it for the right reason. Not because it feels nice, but because we understand what the number actually controls.

What we got wrong wasn't the specific number three. What we got wrong was thinking we could design a marketplace from first principles without talking to the people using it. The cap might be fine. Or it might need to be higher. Or it might need to be smarter, counting only rejected requests or letting Plus tier users ignore it entirely.

Right now, we're just listening. Watching who upgrades and why. Watching what conversations happen between hosts and renters when someone hits the wall. Watching whether the friction we created is actually useful friction or just friction.

That's what launch teaches you. Not that your initial design is good or bad. But that the design is just your first hypothesis. The real test is what happens when hundreds of people start depending on it to find their next studio, their next meeting room, their next event space.

Why this matters for a two-sided marketplace

Findr lives between two groups of people. Renters looking for space. Hosts with space to share. Every decision we make affects both sides in different ways, and those effects aren't always obvious until people are actually using it.

A cap that feels protective to us might feel arbitrary to a renter. A filter that seems smart to us might mean a host's perfect space never gets discovered. That's the complexity we're learning to sit with.

The three-booking limit isn't a mistake we regret. It's a decision that's already teaching us something more valuable than any design exercise could have. It's teaching us how to watch what we've built, and how to change our minds when the evidence suggests we should.

When you're building something that connects two different groups of people, how do you know whether your constraints are protecting the marketplace or just protecting your own assumptions about what people need?

Ready to try Findr by MRVL?

One tap to download. No sign-up wall.

Get it on the App Store

Want to try Findr?

Visit Findr →