Case study · Hospitality & Travel
Revora
A verification-first stay marketplace, live.
Live
Web · iOS · Android
Product strategy, UX direction, payment-flow planning, platform messaging
Context
Booking a stay in Kerala or elsewhere in India still means guessing. Listings are inconsistent, photos are unreliable, and there's no shared standard for what a property actually is before you arrive. That gap between what's shown and what's real is the problem Revora starts from. Rather than compete on volume of listings, the premise is narrower: build a marketplace where every hotel, villa, resort, and homestay has been through an actual verification step before a guest ever sees it. The initial focus is Kerala and India, a market where trust in accommodation discovery is thin and worth building deliberately rather than assuming.
Why verification is the product
It would be easy to treat verification as a badge, a checkmark bolted onto an existing listings model. I didn't want that. Verification had to shape the product from the ground up: what a host must submit before going live, what an approval workflow checks for, and how that status is communicated to a guest at the exact moment they're deciding whether to book. So verification isn't a feature sitting beside search and booking, it's the filter every other part of the product runs through. If a property isn't verified, it doesn't get the same visibility or the same guest confidence signals.
A marketplace of two sides
A marketplace has to work for two audiences that want different things at different speeds. Guests want fast, trustworthy discovery, search, compare, book, done. Hosts want a manageable onboarding process and a dashboard that doesn't feel like a second job. Designing both meant planning the guest journey (discovery through verified-stay browsing to booking) alongside host onboarding and the dashboards hosts use to manage listings and availability. Neither side can be an afterthought to the other, which is the real complexity of building a marketplace rather than a single-sided storefront.
Booking and payments
Money changing hands is where a marketplace either earns trust or loses it permanently. Building the booking and payment flow meant working through what has to be true before a payment is even attempted, property verification status, availability, correct pricing, and then what happens when it doesn't go cleanly: failed payments, retries, and the guest-facing messaging for each state. The flow and its failure states are built, the unhappy paths handled rather than left for later, so verification, pricing and the messaging around a payment all hold before money is ever at stake.
Operating the platform
A marketplace isn't done once the interface exists, it needs people and process behind it. Properties need review before they go live, verification claims need checking, and hosts need a queue that doesn't stall their onboarding. That's an administrative system as much as a guest-facing one: approval workflows, verification queues, and a dashboard for whoever is running that review. Designing this made clear that a marketplace is an operations business wearing a product's interface, the admin tooling matters as much as anything a guest sees.
Where it stands
Revora is live across web, Android, and iOS, a complete product rather than a prototype. The verification-first model, the guest and host journeys, the booking and payment flow, and the administrative approval systems are all built and in place. No booking numbers, property counts, or traction figures are quoted here, what stands behind it is the finished product itself, a verification-first marketplace running across all three platforms.
Working through Revora clarified something I hadn't fully internalized before: a marketplace's product decisions and its operational decisions are the same decisions, just described differently. Verification is both a UX pattern and a review process someone has to run. Trust between two sides of a market isn't a design element you add, it's the thing the entire system has to be built to protect, from the first screen a guest sees to the queue a host waits in.