0 → $100M: Scaling RedAwning's Vacation Rental Platform

Starting from Zero

When I joined RedAwning two months after its founding, Airbnb was barely out of its first year and almost entirely focused on spare rooms. The bulk of the short-term rental market — professionally managed properties — was largely untouched.

The website was nearly nonexistent. The backend was just being built. The CEO was focused on sales; the other co-founder was part-time in an advisory role. I was the person who had to make the product actually work. I built the onboarding flow for property managers. I built the reservation process. I wrote the first booking confirmation email by hand when we processed our first rental.

In those early years, I owned everything that wasn’t sales: technology, operations, customer service, and process. It wasn’t a CPO role yet — it was whatever needed to exist.

The Lead Response Problem That Changed Everything

The industry’s standard at the time was to require guests to request a booking, wait for a response, and hope the property was still available. Most of those requests were simple: is this available? How many beds? We saw an opportunity.

I built a CRM system that checked availability in real time and replied to a guest inquiry within seconds, with accurate property information. This required solving a genuinely hard problem: getting reliable availability data. I built a system that checked every available source hourly and again at the moment of each inquiry. Lead response time dropped from hours to under a minute, and conversion followed.

This wasn’t just an operational win. The availability infrastructure I built to power that system became the foundation for everything that came next.

The Strategic Pivot: Stop Competing, Start Enabling

As our property inventory grew, the demand side wasn’t keeping up. We tested all the standard digital marketing approaches. None of them moved the needle at the scale we needed. So we started listing properties on existing platforms like VRBO and HomeAway, and something clicked.

The insight was simple but significant: what if we weren’t trying to be the next Airbnb? What if we could use Airbnb, Booking.com, Expedia, and every other major platform as our distribution channel instead?

We would be the layer underneath — managing inventory, availability, and reservations across all platforms simultaneously, so that a property manager could list once and appear everywhere. That became the business.

Building the Infrastructure to Make It Work

The platform we’d built wasn’t designed for two-sided real-time API connectivity at scale. When large partners sent or received bulk updates, the resulting floods of reads and writes would collapse our database replication and defeat our caching. We needed a different architecture entirely.

We shifted to an event-driven model: change detection to limit unnecessary writes, SQS queues to smooth load spikes, containerized services we could scale horizontally for bursts, and sophisticated retry logic to protect against fragile partner APIs. This let us consume large property datasets quickly while protecting both sides of the platform from cascading load.

When Booking.com — after a year of conversations — finally reached out to relaunch their struggling vacation rental platform with reliable inventory, we were ready. The partnership was at least 10x larger than any we’d had before and effectively doubled our revenue overnight.

Turning Supply into a Growth Engine

Getting properties onto the platform was its own strategic problem. The answer came through partnerships with property management software companies — the systems that property managers already used to run their businesses. We built API connections into those platforms, giving us a direct technical pipeline to their property data. In exchange, we offered the software companies a transaction commission on every booking we generated for their clients, turning what could have been a cold outreach problem into a partnership with built-in economic alignment.

Once a software partner was connected, we could reach their entire client list with a compelling offer: list with us, appear everywhere. The PMS partnerships became our primary supply acquisition channel.

We engineered the onboarding pipeline to match. New property data could flow in, get cleaned and enriched, and go live dynamically — without manual intervention at scale. We were onboarding roughly 1,000 properties per week, a number that required both serious operational process and the technical infrastructure to back it up.

Closing the Loop on Demand

Supply growth only compounds when demand grows with it. More distribution channels meant more demand sources, which raised revenue per property. Rapid property growth combined with expanding distribution and improving per-property revenue created the flywheel that drove our sustained ~300% yearly growth.

We also invested in direct booking channels — our own website and mobile app — which let us capture bookings without paying platform commissions, improving margins on every transaction. The sheer volume of properties we carried gave us strong SEO leverage, and visibility on third-party platforms drove traffic back to our own channels. We acquired several smaller direct booking sites along the way, adding their audiences and inventory to the flywheel.

By the time the business was fully scaled, the model was self-reinforcing: more properties attracted more distribution partners, more distribution raised revenue per property, and higher revenue per property made us more attractive to new property managers. The infrastructure we’d built to solve a lead response problem had become the engine underneath a $100M platform.

Building the Organization

The team grew from me and a few early hires to 150 people across three offices. One early employee’s decision to relocate to Indonesia turned into a deliberate expansion: I built a team there spanning data operations, engineering, and technical product management. We ran 24 hours a day, with US teams passing work to Indonesia at end of day and back again by morning. It was a genuinely distributed operation, and it gave us a structural advantage on execution speed.

At peak, I was managing 30 engineers and 3 product managers, across a platform processing tens of millions of data records daily, connected to the world’s largest travel booking companies.