About
Revenue software for the
properties it was never built for.
Revenue management has existed for decades — for chains, with dedicated teams and contracts to match. The independent stay got a base rate and a weekend markup. myrevai is an attempt to close that gap without pretending the two problems are the same.
- Origin
- Built inside a homestay platform
- Status
- Independent product
- Market
- India first
- Stance
- Explainable over autonomous
Where it came from
It started as a feature.
The engine behind myrevai was built inside a property management platform used by Indian homestays and small hotels. It began as a pricing helper, grew a competitive intelligence layer when it became clear that a rate without a market is a guess, then a metrics layer to check whether any of it was working, and finally a profit view because revenue kept flattering itself.
Along the way the same request kept arriving: property owners already running something else wanted the intelligence without changing their operations. So the five modules were pulled out into a product that reads from whatever you use today and writes decisions back once you approve them.
That history shows in the design. Everything here was built against real bookings, in rupees, with owners who would notice immediately if a number was wrong — and who told us when it was.
How we build
Six commitments that constrain the product.
These are not values on a wall. Each one costs us something — a feature we did not ship, a claim we cannot make, a number we have to qualify.
Publish the weights
The pricing formula, the seasonality curve and the day-of-week factors are all documented. A recommendation you cannot interrogate is one you will eventually stop trusting.
Recommend, do not act
The system proposes; the owner disposes. Autonomy is available, off by default, and always bounded by a floor and ceiling the owner sets.
Say when you do not know
A new property gets "not enough data", not a fabricated health score. A stale comp set is labelled stale. Confidence is capped at 95% because certainty is not on offer.
Spend other people’s money carefully
Every external call is metered against real recorded usage, cached where it can be, and stoppable by a switch that actually stops it.
Isolate by default
Property data is scoped to its owner on every query. Conversations, metrics and recommendations never reach across accounts.
Be specific about where we are
This is a product for the Indian market first: rupees, IST, monsoon seasonality, Diwali demand, and data protection obligations taken seriously rather than boilerplated.
On the numbers you will not find here
No average uplift. No customer quote we wrote ourselves.
Revenue software is full of “35% average increase” claims. The honest version is that the uplift depends entirely on how far your current pricing is from what the market would bear, and that varies enormously between a Coorg homestay and a Goa villa.
So we do not publish one. What we will do is run your own history through the engine and show you, date by date, where it would have priced differently. That number is yours, it is checkable, and it is the only one worth having.
Figures on this site
Illustrative unless stated otherwise. They show the shape of the output, not a customer result.
Screenshots
Captured from the running application. The property and its data are a demo account.
Pricing weights and factors
Exactly the values the engine uses. If they change in the code, they change here.
Quotas and limits
The real enforced limits, published so you can plan around them.
What's next
Where the engine is heading.
The current model is a transparent heuristic — deliberately, because a property owner can read it and argue with it. The next step is to let the engine learn each property's own curve from its history, while keeping the published weights as the explanation layer rather than replacing them with something nobody can inspect.
Beyond that: weather in the demand signal for hill and coastal properties, review sentiment as a rate factor, rate-parity checks against your own OTA listings, and measuring recommendation quality against what actually sold rather than what we predicted.
Forecast accuracy is already logged against real room-nights sold. That is the scoreboard we intend to be judged on.
Judge it on your own season.
Send a booking export and we will show you what the engine would have done with it — including the dates where it would have been wrong.