Deep Dive: Propexo

AI implementations start with good intentions. For overworked operating teams, they sound too good to be true: agents that autonomously move across systems, work toward goals, and take repetitive work off humans’ plates.

But reality often hits a snag: the data agents need sits in silos across various systems, and accessing it isn’t always easy. And even when operators finally get access to their data, they often find it messy and unstandardized. While AI systems can tolerate some data cruft, poor data quality can make AI implementations useless…or worse.

So before AI can work, operators have to take on a different but related initiative: getting their data right. For operators working across multiple systems, managers, and jurisdictions, that is often about choosing “good enough” over perfect.

In today’s letter, we’ll explore the critical data-cleaning quest many operators are embarking on. We’ll do it through the lens of Propexo, a company we’ve discussed before here on Thesis Driven, headed up by Co-Founder and Chief Executive Officer Remen Okoruwa. They featured heavily in our popular (and lengthy) deep dive into the future of the property management system, when they were building an integration library to help proptech companies connect to property management systems.

Now, they’re using those tools to help real estate operators sort out data messes. In an April 2026 guest letter for Thesis Driven, Okoruwa argued that operators should own their data rather than leave it locked in their property management systems; Propexo is building the tools to put that ownership to work. By doing that, they’re aiming to build real estate’s Palantir.

A Mess of Data

People who write about data cleanliness and AI do not make it easy for the average person in the industry to understand what they’re talking about. There’s much discussion of “entity resolution,” “semantic layers,” and “ontology.” If multifamily operators are talking like late-19th-century German analytic philosophers, we know things must be in bad shape.

The reality is less confusing than it sounds, and understanding these terms can help data people describe data messes.

“Entity resolution,” for instance, means that all the things in an operator’s universe — tenants, units, leases, properties — are represented cleanly across systems. That is, John Smith in Unit 4B in the PMS is the same John Smith in the CRM, the same John Smith who submitted an HVAC work order, and the same John Smith who submitted a Google review referencing that work order.

There are not two John Smiths. There are not several unrelated John Smiths. There is one John Smith; he lives in Unit 4B, and he has an HVAC issue.

The “semantic layer” is a standardized set of definitions. This part often gets overlooked, and it’s easiest to understand through an example: When someone asks “What’s the average review score at properties in the Southeast with more than 10 open work orders?”three terms in that question are ambiguous:

Open work order: Does that include “on hold”? Pending vendor scheduling? Completed but not yet closed out by the PM? Is a duplicate ticket for the same leak one order or two? The semantic layer pins it down. For example, it might say an open work order is anything in status New, Assigned, or In Progress, excluding canceled and merged duplicates.
Southeast could mean the Census definition, an operator's asset management team’s regions, or the way its property management org is split. The semantic layer says Southeast means the operator's regions, so Charlotte might count while a Texas property doesn’t.
Review: Google only, or also ApartmentRatings and Yelp? Do 5-star scales and 10-point scales get normalized? Are reviews from former residents included?

The semantic layer ensures that everyone is talking about the same thing. The ontology ties it all together by mapping what kinds of things exist and how they relate. For example:

A portfolio contains properties;
A property contains buildings, and buildings contain units;
A unit has leases, and a lease has residents.

This may seem simple until an urban operator buys its first garden-style property and realizes its ontology doesn’t know what to do with a property that contains multiple buildings.

They fit together like this:

Entity resolution works out that “John Smith” in Yardi, “J. Smith, Unit 4B” in the work order system, and “johnsmith88” on Google Reviews are the same person.
The ontology knows that John lives in Unit 4B, that 4B is part of the Riverside property, and that his HVAC ticket and his 2-star review both attach there.
The semantic layer decides whether his ticket counts as “open” and whether Riverside falls in “Southeast.”

Get those three things right, and you’re 95% of the way to having AI-ready data. Doing it across a real operator’s systems is the hard part.

**Review queue.** Agents propose actions with the evidence behind them; managers approve, edit, or reject them, and approved actions are written back to Yardi.

Speaking Every System’s Language

Aligning data across different systems was at the core of Propexo’s initial product. As we’ve covered in the past here at Thesis Driven, the company built a software library that allowed technology builders — usually proptech point solutions — to write one set of code that communicated across multiple property management systems, saving entrepreneurs countless hours building separate integrations for Entrata, Realpage, Yardi, and others.

Building that kind of product requires a deep understanding of how each property management system categorizes data and processes information. If a proptech company’s app wants to add a note to a lease application across multiple systems, it needs to understand how each system thinks and acts. It’s no coincidence that Okoruwa has been a source for us when we want to better understand the weeds of PMS technology for a story.

That understanding also helps operators untangle their own data messes. In many cases, those messes come from working across systems that organize information differently — for example, various PMS platforms and point solutions. Plus, Propexo’s work in the weeds of integrations gave them more than 100 connections to tools ranging from major PMS platforms to leasing and marketing tools, payments platforms, and maintenance dashboards. Those are the exact platforms operators are looking to tie together.

So about a year ago, the Sequoia- and Fifth Wall-backed startup, fresh off a new fundraise, decided to shift focus: instead of serving proptech startups, they’d bring their expertise to real estate operators. Their operator customers now include Cardinal Group and S2.

“Doing PM software integrations meant we were very good at looking at different systems that were generally talking about the same thing but had very different data structures and labels for all of that data,” said Okoruwa. “And we saw that operators didn’t just need help getting their data into the right place but figuring out what to do with it once it was there.”

While many discussions emphasize systems integration that lets data move, the integration is the part operators would rather never maintain. Solving the three layers we introduced earlier is a change-management exercise that requires tough work to win alignment across an organization. Diverging definitions of a key term or data hierarchies often reflect genuine differences in how parts of an organization think and operate.

Okoruwa's engagements often start by helping operators get all their data into a data warehouse they own, replacing scattered sources of truth (the PMS, various point solutions, and spreadsheets) with one central store, often in Snowflake or Databricks.

Once the data is in the right place, agentic workflows become possible. Okoruwa lists a handful of tools he regularly implements, including maintenance SLA monitors, contract expiration trackers, marketing attribution dashboards, and lease trade-out reports. The platform's wide set of integrations also makes it straightforward for operators to flag potential data quality issues. For instance, while reviewing work orders, an operator may find the same work order duplicated across multiple systems and clean it up in one interface.

**Asset manager briefing.** The owner sees the month’s close against budget, anomalies with a dollar figure on each, and the share of the property manager’s work that agents now handle.

The usefulness of this kind of service reflects a difficult reality in real estate tech: many operators, particularly third-party managers, can’t rely on a single system. Clients, for instance, often force their third-party manager to use their favored PMS. Even operators with in-house management may find that institutional investors on some deals require a specific technology platform.

That creates massive headaches for cross-portfolio analysis, coordination, and tooling that no single property management system can solve.

“All the cool new Realpage AI capabilities only work well if you’re only using Realpage products in your stack. The moment you have part of your portfolio on Yardi, part of your portfolio on Entrata or MRI, Realpage can’t see any of that,” said Okoruwa.

But my real interest is what it means for the future of property management systems.

Moats No More?

As regular Thesis Driven readers know, we’ve extensively covered property management systems’ battle with point solutions, and often their own customers, over data access. In his company's first iteration, Okoruwa was at the center of that fight, working with proptech companies to make PMS integrations easier.

Now, he’s building for real estate operators. But Propexo’s work today is no less of a challenge to PMS moats.

“For operators, the real source of truth is no longer a PMS,” said Okoruwa. “The PMS is where the work gets done. For larger operators it’s becoming a book of record. The answers and insights live in a warehouse they own.”

**Anomaly detail.** One finding expanded: the trend, likely cause, dollars at stake, and suggested fixes, each with an owner.

We are a long way from property management systems losing their position in the market. But the rise of data warehouses as the new primary source of truth is surely concerning. If the PMS is no longer the source of truth for key property and tenant data, or for the three layers we described above, then it is little more than a big bundle of features. And bundles of features, no matter how big, have no moat in a post-AI world.

Companies like Propexo have tremendous wood to chop by helping operators organize and make sense of messy data. But as we’ve previously discussed here on Thesis Driven, this next generation of technology companies won’t look like the neat proptech point solutions of years past.

“Old Propexo was a straightforward SaaS company,” noted Okoruwa. “Where we’re going is a company that looks a little bit more services-focused. That white-glove model requires embedding our staff with clients during the build and deployment to ensure our tech actually works and is delivering the ROI expected. It also means that we’re part of change management in these organizations.” With that approach, Propexo follows a broader trend toward vertical integration and services models rather than pure software.

Whether Propexo becomes real estate’s Palantir is a question for the next few years. But the bigger shift is already underway: the layer that defines what a unit, a lease, or an open work order actually means is moving out of the PMS and into warehouses that operators own. Once that shift is complete, the PMS companies will have to compete on what their software does rather than on the data they hold.

–Brad Hargreaves