Right now at Renjoy, we are running two architectures simultaneously. Our legacy stack — the patchwork of SaaS tools we stitched together to get to 200+ properties — is still handling live operations. Guests are checking in, handymen are getting dispatched, owners are receiving reports. The plane is flying.
And we're tearing it apart mid-flight.
We are building an AI-native operating system called RenjoyOS. Instead of bolting AI features onto our existing tools, we're rebuilding the foundation. It starts with a new database plus orchestration layer and internal dashboards. We're creating AI agents that don't just answer questions but actually do operational work — scheduling housekeeping, enriching maintenance tasks, generating briefings, resolving guest issues autonomously, vetting potential new team members.
It is, without exaggeration, the hardest thing we've done so far.
What "bolted-on" actually looks like
Like many operators, we initially relied on a collection of separate, top-tier tools for each core function: a PMS for reservations, a dedicated platform for housekeeping and maintenance tasks, a guest messaging system, a pricing engine, and so on. Later, we began integrating various AI components — a specialized AI messaging bot, automated workflows — on top of this existing structure.
It works, but not well enough.
The problem with bolted-on AI is that it hits a ceiling fast. Your AI guest messaging tool can answer questions, but it can't see the maintenance task that was just created for the same property. Your automated dispatch can assign a technician, but it can't check whether that tech is clocked in because that data lives in a completely different system. Your AI-generated owner reports pull revenue data from one source and cleaning costs from another, and reconciling them requires a human who holds the full picture in their head. Trying to stitch all this together with bolt-on tools led to a massive amount of tech debt we now have to disentangle.
You feel like you're making progress because each individual tool is impressive. But the operating model underneath hasn't changed. You're still a property management company with AI features. You're not an AI-native operator.Tweet this
We had over a dozen SaaS tools, each with its own data model, its own API quirks, its own limitations. Our "AI strategy" was really just a collection of point solutions that couldn't talk well with one another. We were spending $300k+ a year on software and still relying on people to be the integration layer between systems.
The decision that breaks everything (temporarily)
Earlier this year, we made the call to stop adding features to the old stack and start building the new one. We hired a Head of AI whose job description opens with this line: "Not a PM company with AI bolted on — an AI-native operating system that happens to manage properties."
That sounds great in a job posting. In practice, it means we are now maintaining two systems while building a third. Our legacy task management platform is still dispatching cleaners every morning. Our new operations platform is being onboarded in parallel. Our custom-built orchestration layer runs 100+ automated workflows that bridge the gap between old and new. And our internal AI agent, Joy, is slowly absorbing functions that used to require three different tools and a Slack message chain.
Some days the Frankenstein software stack holds. Some days it doesn't.
Last month, an issue broke our calendar and listing syncs from our PMS. Guest-facing data went stale. The fix required debugging an authentication gateway pattern that exists solely because we're pulling data from a legacy system into a new database that wasn't designed for the old system's API rate limits. Not an AI problem — a "two architectures at once" problem.
We also still have 100+ legacy database tables from our old system of record. We can't query them all effectively and we can't build against them without using a ridiculous number of tokens. But we can't remove them yet because downstream workflows still reference them during the migration. They just sit there, a monument to tech debt and transition tax.
The pain is real — here's what it actually costs
I want to be specific about this because most transformation narratives skip the ugly middle.
Context switching destroys productivity. When the team is maintaining an old system, building a new one, and keeping them synchronized, they're not doing any of those things well. Research suggests it takes 20+ minutes to fully refocus after switching between complex systems. We feel that every day. Our team is juggling legacy maintenance, new feature development, and migration work simultaneously.
We pay twice for everything for a time. During a parallel migration, you're licensing the old platform and building the new one. You're training people on both. You're writing documentation for systems that will be deprecated in months. System migrations increase costs by 30–50% and that tracks with our experience.
Our team gets exhausted. We've found the team's willingness to support organizational change has not kept pace with the lightning advances within AI. We're a 40-person company asking people to learn new tools, adapt to new workflows, and maintain the old ones — all while guests keep checking in and owners keep expecting reports on time.
Why we're doing it anyway
Here's what I try to keep telling myself: organizations systematically avoid the behaviors that actually drive success specifically because those behaviors create discomfort. Most companies focus on the easy stuff — collaboration, continuous improvement, teamwork. They neglect accountability, decisive action, and performance pressure. The uncomfortable stuff.
The difference between success and failure isn't intelligence but rather a willingness to embrace the suck.
I think about this every time somebody complains about a tool in our daily Renjoy Rally. The pain isn't a sign that the strategy is wrong. The pain is the strategy. If it were comfortable, everyone would do it, and it wouldn't be a competitive advantage.
The pain isn't a sign that the strategy is wrong. The pain is the strategy. If it were comfortable, everyone would do it, and it wouldn't be a competitive advantage.Tweet this
Our bet is that the best vacation rental manager in the world — the one where no owner chooses to leave — is an AI-native operator with the highest-paid frontline team in the industry, undercutting competitors on price while delivering 4.9+ guest experiences. That's only possible if the operating system is radically more efficient than anyone else's. And you don't get a radically different operating system by adding AI features to the same architecture everyone else is using.
The lesson I'd share with anyone considering this
The plane metaphor implies speed and drama but I've found the reality is slower and quieter. It's replacing one workflow at a time. Migrating one data table at a time. Onboarding one new platform while decommissioning the old one. And doing it all while answering guest messages at 11pm and making sure the cleaners know which units to flip tomorrow morning.
If you're running a company right now and you feel the pull to fundamentally change how your business operates — not just add a new tool, but rebuild the model — I'd offer this: the discomfort you're feeling is good. When the transformation is easy, you probably aren't transforming. When it's painful and messy and you're maintaining two systems and your team is tired and things keep breaking in the seams — that's usually a sign you're doing something real.
Go toward the pain because it's where the moat gets built.Tweet this