Viraalay

Viraalay is a brand of Manpeksha Hospitality LLP, headquartered in Navi Mumbai and founded by Tarun Bafna, Shubham Bafna and Apeksha Talesara. The name joins two Hindi words, विरासत (heritage) and आलय (abode). The portfolio matches it: a blue heritage haveli near Udaipur's City Palace, a chilli-farm villa outside Jodhpur, a five-bedroom mansion with a home theatre and a library, and a run of two-bedroom serviced apartments in Jaipur and Udaipur.

Three rules hold across every property. The kitchen is pure vegetarian. There is no single-use plastic. A caretaker lives on site. Nightly rates run from about ₹4,500 for a Jaipur apartment to ₹65,000 for Kvanya Mansion in Udaipur.

Viraalay doesn't own most of these homes. It partners with owners, runs the hospitality, and manages calendars, rates and channel listings through Guesty, its property management system. That last detail shaped the entire project.

Three problems, and each one made the others worse.

Bookings lived on other people's platforms

Like most villa operators, Viraalay's reservations arrived mainly through Airbnb and WhatsApp. That is the industry norm: Hostfully's 2025 survey of 256 property managers puts Airbnb at 45% of bookings on average and direct at just 20%. The cost of that mix is not small. Hosts who connect through property management software are placed on Airbnb's host-only fee, which Airbnb states is 15.5% for most hosts. On a ₹30,000 villa night, ₹4,650 leaves before the caretaker has made a bed. Booking.com sits in a 10% to 25% band depending on property type and visibility programmes, per StayFi's November 2025 guide.

Search for a Viraalay villa by name and the aggregator listing outranked the brand's own site. So the brand paid for its own demand.

Guesty was the source of truth, and the website couldn't see it

Rates, blocked dates, guest counts, house rules, photos and addresses all lived in Guesty. Any website that showed a price would be wrong within days unless someone retyped it. The team had already seen what stale numbers do to trust. Nobody wanted a second system to keep in sync by hand.

The team couldn't run the site themselves

Seasonal offers, a new property, a corrected house rule, a fresh set of photos: each one had to go through a developer. Viraalay wanted the marketing and revenue teams to publish on their own, with guardrails so a well-meaning edit couldn't break a URL or a price.

Add a hard window (proposal signed mid-June, live wanted by end of July) and the brief was clear: a site that sells the experience, books the stay, stays correct on its own, and can be run by a small team.

• A new brand website on Webflow, designed in Figma first: home, properties, individual property, destinations, about, experiences, contact, careers, partner with us, legal pages.
• A CMS the team could run: properties, destinations, reviews, careers, cancellation policies, FAQs.
• A direct booking flow with live availability, exact quotes, coupons, GST and online payment.
• A two-way link to Guesty so property data and prices stay current without retyping.
• Analytics, search console, schema, sitemaps, lead forms with attribution, WhatsApp, and on-page SEO.
• Training, documentation and a clean handoff.

We ran the project in the order we run every site: strategy and sitemap, moodboard, wireframes, Figma design, Webflow build, then integrations, SEO and testing, then launch and training. Booking engine work ran in parallel with the Webflow build from the second week because it was the long pole.

Villa guests don't buy a room type. They buy a weekend they can picture. So the design puts the property and the place first, and keeps the booking controls in reach without letting them dominate.

Brand language

Viraalay already had a warm, editorial identity: deep maroon, cream, Devanagari accents. We built the type scale and spacing system around it rather than importing a generic "luxury" template. Spaces inside the homes keep their real names. At The Blue Root the rooms are Darikhana, Badi Medhi and Choti Medhi. At Kvanya Mansion the pool is रोशनी Bagh and the kitchen is शाही Rasoi. Those names do more for the brand than any tagline, so the property template gives them room.

Search-first homepage

The hero is a full-bleed video with a compact search bar: where to, check-in, check-out, guests. Guests already know this pattern from the OTAs, so we didn't fight it. Below it: featured properties, the three destinations, the "Viraalay way" (handpicked homes, pure vegetarian stays, zero single-use plastic), experiences, guest reviews under the heading "Atithi Devo Bhava", and a live Instagram feed.

The property page

This is the page that has to do the selling and the booking, so it got the most design time. In order:

• A gallery of up to 25 photos plus a video, with a proper lightbox and next/previous controls.
• A sticky booking widget: dates, guests, rooms, coupon field, a live total with taxes, and the line "You will not be charged until you confirm".
• At-a-glance specs (guests, bedrooms, baths), rating and review count, and "Great for" tags such as workations, celebrations, senior citizens.
• About this home, amenities as scannable chips with a "show all" toggle, and accordions for house rules, meals, cancellation policy and safety.
• Spaces: one gallery per bedroom, living room, pool, theatre or garden, each with its own description.
• Guest reviews with a four-way breakdown (staff, cleanliness, meals, experience).
• Spotlight and experiences, shown only on properties that offer them.
• Map with directions, nearest airport and station, tourist spots and restaurants nearby.
• FAQs grouped into six tabs, similar properties, brochure download, share, WhatsApp and call.

What the client's review changed

The 29 July go-live review was blunt and useful. Desktop fonts felt bulky. The search banner hid the video. Property pages scrolled too fast. The lightbox took 1.5 seconds to close. Corners were a mix of rounded and sharp. We shipped the fixes over the following days: tighter type scale, slimmer search bar, standardised rounded corners, a smaller lightbox close button, a "call us" dropdown on desktop with phone and WhatsApp, and a three-field search on mobile. The site you see today is the one the client's team pushed us to make.

Mobile

On phones the booking widget becomes a bottom bar showing the selected dates and guests. Tap it and a sheet slides up with the full form. That one pattern kept the property content readable on a 390px screen without hiding the way to book.

The site is a Webflow build with a small amount of custom JavaScript for search, maps and the booking sheet. The CMS is where most of the thinking went.

Collections

Seventeen CMS collections, most of them small reference lists that keep the property template honest.

• Properties: the core collection, with around 47 fields the Guesty sync maintains plus the editorial fields the team owns (tagline, "great for", spotlight images, video, brochure, meals, similar properties, and since late August the advertised "from" rate).
• Rooms: one item per bedroom, living room, pool or theatre, so each space gets its own gallery and description.
• Amenities, Great For and Property Type: reference lists that power the filters and the chips, with a mapping table that translates Guesty's amenity names into Viraalay's.
• Locations: Udaipur, Jaipur and Jodhpur, each with its property list and count kept current by the sync.
• Reviews: imported from Guesty's Airbnb reviews, linked to their property, with averages and a short summary recomputed on import. A review the team adds by hand is never overwritten.
• Bookings: every checkout writes a record here with a status (awaiting payment, confirmed, failed, cancelled), so the reservations team can see the pipeline inside Webflow.
• FAQs (applied from one reviewed JSON file so the whole set can be proofread in one place), Cancellation policies, Careers, Team, Blog and Blog categories ready for content, Add-ons reserved for future extras, and a drafted Property Sync template that exposes every raw Guesty field for debugging without creating thin public pages.

Filters and conditional content

On the properties page, guests filter by price, rooms, 40+ amenities, "great for" tags and collection (luxury villas, premium apartments, heritage homes, farm stays, unique stays), with four sort orders. Sections that only some properties need, such as spotlight and experiences, are switched with conditional visibility per item, and we trained the team to add or remove those slides themselves.

Guardrails for a non-technical team

• A staging domain (viraalay.webflow.io) for internal review before publishing to viraalay.com, with search indexing disabled so it never competes with the live domain.
• Unpublish, never delete, for retiring a property.
• Images compressed to WebP inside Webflow, under the 4MB asset cap, with SOPs for icon swaps and image replacement.
• Forms routed by purpose: guest and brochure enquiries to the reservations inbox, partnership enquiries to business development, applications to HR. Every submission carries its attribution (original referrer, UTM parameters) so the team can see which channel produced the lead.

One small war story. Two days before launch the CMS refused new items on a plan that should have allowed 20,000. Webflow support confirmed the limits had been mis-provisioned and reset them within a day. We mention it because launches always have one of these, and the tracker is what keeps them from becoming a crisis.

1. Search by destination, dates and guests. Results come from a properties index the backend keeps warm.
2. Open a property. With no dates chosen, the widget shows the advertised "from" rate with a strikethrough, so offers read as offers. At launch that number was computed from the Guesty calendar (the lowest bookable night in the next 90 days). On 25 August, at the team's request, we handed it to a CMS field that revenue sets deliberately, and the sync never touches it.
3. Pick dates. The script asks the backend for a live quote, Guesty prices those exact nights for that guest count, and the live panel replaces the static card. This number includes GST and fees and is the one checkout uses. The chosen dates also sit in the URL, so a refresh re-quotes them.
4. Apply a coupon (VIRAASTAY at launch), accept the house rules and cancellation terms, and click Book Now. The backend re-creates the quote itself (a price posted by the browser is ignored), writes a booking record marked "awaiting payment", and returns a signed PayU form.
5. PayU takes the payment and calls back. The backend accepts the result only when three checks pass: the reverse hash matches, PayU confirms the payment server to server, and the captured amount equals the recorded amount to the paisa. Only then is the reservation created in Guesty, the booking marked confirmed, and the guest sent to a confirmation page with a VRL reference number.

How the Guesty sync keeps the site honest

This is the part most villa websites get wrong, so here is exactly how it behaves.

• Listing edits in Guesty fire a webhook. The property is updated and published within seconds, two minutes at most.
• Rate and calendar edits are debounced for three minutes (revenue managers change many nights at once), then synced.
• A full sweep of all 11 listings runs every six hours as a backstop, throttled to stay inside Webflow's rate limit. About two minutes per run.
• Availability, per-night rates and minimum stays are read live on every page view and never stored in the CMS, so a blocked date can't leak.
• Name, slug and meta description are write-once. They are set when a property is first created and never re-synced, so a rename in Guesty can never break a live URL or create duplicate meta tags. Renaming in Webflow pushes back to Guesty instead.
• Advertised rates are guarded, not synced. Since 25 August the team owns the "from" rate in the CMS. A checker script compares the CMS, the page's structured data and llms.txt and fails loudly on any mismatch, because a stale figure in structured data can be shown by Google as the price.
• Amenities are add-only. The sync will add "Jacuzzi" from Guesty but never strip "Power backup" or "Caretaker" that the team added by hand.
• The sync never writes an empty address. If Guesty's full address is blank it falls back to city and state, and if that is blank too it leaves the CMS alone.
• A new Guesty listing becomes a draft property, not a live page. Someone reviews it, then publishes once. After that it maintains itself.
• Photos are deliberate, not automatic. An admin button pushes up to 25 images per property (Webflow's cap) as real assets with responsive srcset, backs up the previous state first, and offers rollback. Room galleries are assigned from Guesty photo captions.

The team gets a password-protected admin page with eight allow-listed maintenance jobs: sync details from Guesty now, push property photos, assign room photos from captions, import guest reviews, apply FAQs, re-register webhooks, test credentials, and a status bar that says in plain words whether live pricing is flowing. Jobs run one at a time, are idempotent, and have their output passed through a secret redactor. Nothing on that page can run an arbitrary command.

We learned one Guesty constraint the hard way. Guesty allows five access-token requests per day. On 22 August a few test-credential clicks burned all five and live pricing went dark for a few hours. The fix was structural: the token is cached on a persistent volume and reused for its full 24-hour life, the sync jobs run as child processes of the booking engine so they share it, and the one button that forces a fresh token is now labelled as the button to leave alone.

Monitoring, tests and security

A booking engine is a payments product, so it is built like one. Secrets never reach the browser: the PayU merchant salt that signs each amount, the Guesty client secret and the Webflow write token all live on the server, behind a CORS allow-list, with tokens on every inbound webhook and a secret scanner in the repository. Every property is backed up before a photo push, with rollback, and a full CMS export was taken on handover day.

An hourly health check runs on GitHub Actions, outside Railway on purpose, because a monitor hosted inside the thing it watches goes quiet with it. It calls the live Guesty calendar path, the exact call that failed once on 23 July, and emails on failure. The codebase carries 47 automated tests across seven suites (admin jobs, amenity mapping, checkout terms, Guesty token handling, advertised prices, rich-text sync), all passing at handover.

By the numbers: 96 commits between 23 July and 25 August, about 12,000 lines of JavaScript across 50 files, 20 maintenance scripts, 17 CMS collections, 32 environment variables.

• Guesty (Open API and webhooks) for inventory, pricing, quotes and reservations.
• PayU for payments in INR.
• Railway for the Node.js backend, with a persistent volume for tokens and backups.
• GitHub for source control and the hourly uptime check with email alerts.
• Webflow CMS API for two-way property data.
• Google Analytics 4, Google Tag Manager, Microsoft Clarity, Meta Pixel for measurement and session replay.
• Google Search Console and Bing Webmaster Tools with sitemaps submitted at launch.
• WhatsApp click-to-chat on every page, and an "I'm interested" flow on experiences that sends the guest's stay details straight to the reservations team.
• YouTube for per-property video tours, Instagram feed on the homepage, Google Maps for locations and directions.
• Webflow forms with UTM and referrer capture, routed to three inboxes by purpose.

Let's be straight about the starting point. viraalay.com launched with a Domain Rating of 9 (Ahrefs, September 2026) and no ranking keywords to speak of. For its own villa names, Airbnb outranked it. There is no traffic chart to show five weeks after launch, and we would be suspicious of any agency that showed one. What we did was make the site the easiest source in its category for both Google and AI assistants to understand, so that authority, when it arrives, has somewhere to land.

Entity-first structured data

Every page carries a schema graph rather than a single snippet. The Organization node names the legal entity (Manpeksha Hospitality LLP), founders, contact points, areas served, what the brand "knows about" and an offer catalogue. The WebSite node declares site search. Each WebPage lists the cities and state it mentions as entities. The homepage adds an ItemList of experiences. A property page carries 16 to 20 Service and Offer nodes, plus address, coordinates and payment methods. This is what lets an AI engine answer "vegetarian villas in Udaipur with a private pool" with a real name instead of a guess.

Built to be read by AI crawlers

• An llms.txt that states the facts a model needs in one place: legal entity, cities, property count, price range, food and plastic policies, founders, contact details.
• A robots.txt written for 2026: search engines and AI crawlers allowed, bandwidth-wasting scrapers blocked, thank-you and payment pages kept out of the index.
• Answer-shaped content on every property: FAQs in six groups, house rules and policies in full sentences, distances to the airport and landmarks in kilometres.

Classic hygiene

• Canonical URLs on every page, unique meta titles per property, write-once meta descriptions so the sync can never create duplicates.
• Staging domain excluded from indexing.
• 98 of the 102 images on a property page lazy-loaded; assets compressed to WebP.
• Lighthouse on the homepage: SEO 100, accessibility 96, best practices 96, performance 87 on desktop. Largest Contentful Paint 1.3 seconds, layout shift 0.002, total blocking time 31 milliseconds. Mobile performance sits at 73 with a 2.8-second LCP; the background video is the trade-off, and it stays because it sells stays.

What comes next

Property-level VacationRental schema, destination guides that answer the questions guests actually type ("Udaipur villa with pool for 15 guests"), review velocity through the import tool, and a steady backlink programme. That is the work that moves a DR 9 domain above an aggregator, and it is measured in quarters, not weeks.

• Villa and homestay managers on Guesty, Hostaway or a similar PMS who want the website to book, not just to brochure.
• Boutique hotel groups with a handful of properties across cities, where each property page needs to stand on its own in search.
• Heritage homes, farm stays and serviced apartment operators whose product is the experience, and who lose that story inside an OTA listing.
• Operators recruiting owners. Viraalay's "partner with us" page and form now bring in property owners as leads, the other side of its business.

What made it hard

• Two sources of truth. Guesty for inventory and money, Webflow for storytelling and SEO. Every field needed a decision about who owns it, and the write-once rules on names, slugs and meta descriptions came out of that.
• Data quality upstream. Half bathrooms, missing photo captions, addresses that hadn't been re-geocoded. The sync had to be defensive, and the field map had to be explicit.
• Platform limits. Webflow caps galleries at 25 images and CMS writes at 60 per minute. Guesty caps token requests at 5 per day. All three shaped the design.
• Money. GST, coupons, signed payment forms, a three-check callback and server-side totals. A booking engine is a payments product first.
• The wrong Guesty API, on paper. Viraalay's plan includes the Open API but not the Booking Engine add-on. That turned out to be the better path: the Open API's Reservations V3 creates a reservation from a quote without a card token, which is exactly right when the merchant collects the money through PayU.
• Handing over without breaking anything. The booking URL was baked into the Webflow footer, the Guesty webhook subscription, the health monitor and the server config. Transferring the Railway project whole, rather than redeploying into a new one, left all four untouched.