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. Planning 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. This is payment-flow planning rather than a claim that a finished, live payment system is running today; the goal has been to design the flow and its failure states properly before money moves through it.
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 in active development across web, Android, and iOS. The verification-first model, guest and host journeys, booking and payment flows, and the administrative approval systems are being built and refined together rather than shipped as separate phases. There are no booking numbers, property counts, or traction figures to report — the near-term focus is finishing the core flows across all three platforms and getting the verification and approval workflows operating end to end.
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.