RoomsTonite
RoomsTonite offered last-minute hotel deals in India, but shut down after funding failed and the marketplace could not carry its operating costs.
View original storyProduct snapshot
What it was
RoomsTonite let users book discounted last-minute hotel rooms in India through a mobile app.
Who it was for
Problem / value
Match short-notice traveler demand with hotels that had unsold inventory.
Core workflow
A traveler searched nearby or destination hotel inventory, selected a discounted room, and booked through the app for the same day or a short booking window.
Core dependency
The marketplace needed enough city-level demand, hotel supply, commission margin, and funding runway to stay liquid.
Product form
Pricing model
Commission-based booking model reported by Times of India; exact commission rates, CAC, gross booking value, and contribution margin are not disclosed.
Competitors or alternatives
What happened
Summary
RoomsTonite shut down after a failed fundraising path and cash-flow pressure hit its last-minute hotel booking marketplace.
Outcome
Shut down.
Core risk
Inventory access does not prove marketplace liquidity or sustainable commission economics.
Shutdown reason
Public reports point to failed fundraising, cash-flow trouble, and operating costs that became difficult to carry.
Demand signal
The product addressed a real use case: unsold hotel rooms and last-minute travelers. The public risk is that demand and margin were not strong enough to survive failed funding and rising operating costs.
Distribution issue
RoomsTonite had to win travelers at the moment of booking while hotels could also use larger OTAs, direct channels, and other aggregators. A large hotel list did not prove city-level liquidity or defensible acquisition.
Timeline
- 2014: RoomsTonite was founded, according to public coverage.
- December 2015: Times of India reported RoomsTonite raised $1.5M.
- 2017: VCCircle reported the company closed operations after a failed fundraising bid.
Before you build
Why it matters
A marketplace works only when demand appears often enough, supply responds reliably, and the take rate covers acquisition and operations. Funding delays expose weak liquidity quickly.
Primary check
A booking marketplace needs liquidity, not just inventory. Prove repeat last-minute demand, hotel participation, commission margin, and cash runway in one segment before expanding supply.
Checklist
- Track booking conversion and repeat rate by city.
- Measure active hotel supply, not just signed inventory.
- Build a cash plan that assumes no new funding.
- Which city or route has repeat last-minute demand?
- What commission margin remains after acquisition and support?
- How many hotels stay active without subsidies?
- What happens if the next funding round fails?
- Does supply count translate into completed bookings?
Relevant if
- You are building a booking marketplace, travel app, local inventory marketplace, or discounted inventory product.
- Your model depends on suppliers with perishable inventory.
- You need funding before city-level liquidity is proven.
Less relevant if
- Your product does not require two-sided marketplace liquidity.
- You already own demand through a repeat channel.
- Supplier participation is exclusive and high margin.
Pre-build tests
- Run one city manually with a small hotel set before expanding.
- Pre-sell demand through one repeat channel such as business travel or events.
- Compare take-rate margin against OTA acquisition costs.
Transferable lessons
- Measure liquidity by city and use case, not total listings.
- Model cash runway assuming a funding round fails.
- Treat supplier integrations and support as recurring costs.
If you build this today
Focus on one high-frequency travel corridor or one hotel segment, prove repeated bookings and hotel-side economics, then expand only when commission margin covers acquisition, support, and supplier operations.