Data sovereignty for CRE owners.

Domo Day

Many years ago we had a ritual. Once a month our analysts pulled the latest rent rolls and trial balances out of our property management system, dropped them into a Domo workspace, and we crowded into my office to comb through them together. We called it Domo Day.

I looked forward to it. For the first time we could watch occupancy, trade-outs, and financial performance across every property in the portfolio in one place. None of that was possible inside the property management system itself. It felt like we had finally built the thing we had been asking for.

What we had built was a record of what had already happened. Very good at that. Incapable of anything else.

Every number on those charts was accurate. None of them could tell us where we were going, and no monthly rent roll ever can.

Over time, our operation needed far more than a rent roll or a T-12 could give us. We needed to see what was happening in the portfolio the day it happened, not five weeks later in a format nobody could audit.

That is when we went down the road to data sovereignty.

Those reports are not your data. They are a rendering of it, produced monthly and flattened for distribution. Underneath them, in the system, sits everything that actually explains the numbers. Lease-level history. What every renewal was offered at and what it closed at. Concessions by unit. Screening compliance and outcome tracking. Work order age and how many times a unit came back. Turn cost and turn duration by property and by crew. Delinquency by tenant with an aging trail. Traffic, tour conversion, where the lead came from. Our property managers touched some version of that every single day.

We had to have all of it.

The system of record is not built for you

We went looking for a way to get our records out of the property management system and into something we controlled. I assumed this would be a procurement question. It turned out to be the central problem of the next several years.

There was no modern replication path. No connector. No supported export to a warehouse, no managed sync, nothing a competent data team from any other industry would recognize as normal. You could stand up a pipeline from Salesforce in an afternoon. You could not do it from the software running your portfolio.

What existed instead was a partner interface program. Licensed per interface, priced annually, sometimes per transaction, built on an integration standard designed before the iPhone. The terms are explicit that the interface belongs to the vendor and the party connecting to it acquires no ownership in it. We generated the data, at our properties, with our employees, and reading it in bulk required a license and permission.

There is a second limit that gets less attention and hurt us more. What you can export is whatever somebody decided to expose on a report. Not the record. The report. If a field was not on a stock report, it did not exist for our purposes, and the shape of our analysis was set by decisions made years earlier by people who had never met us.

So we built around it. We scheduled reports to run on their own, dropped the output on an SFTP server, moved it into cloud storage, and reassembled a database from the pieces. I taught myself SQL and Python. We hired data engineers. All of that expense and effort went into reading records we already owned, at properties we already owned, managed by a company we also owned.

I want to be fair here. These systems are good at what they were built for. Leasing, work orders, resident communication, accounting. Decades of refinement sit in those products and I would not run a portfolio without one. My objection is narrow. A system of record should not be the thing standing between an owner and their own records.

None of that is technically hard. It is a commercial choice, and a comfortable one, because an owner who cannot get their data out is an owner who is not going anywhere.

What we learned

Once the data was ours, everything changed at once.

We connected the rest of it. Screening providers, the property-level CRM, the HCM, our investor system, and a long list of external research and market data. We iterated through something like fifty data vendors before we knew which ones were any good, and we wasted real money finding out. Then we modeled it properly, and for the first time I could ask a question about the portfolio and get an answer the same day, from a number I could trace back to its source.

That is when we got ambitious in the wrong direction.

We looked at the property management system, and at what we had just built, and concluded we could replace it. Everything felt possible, so we started building our own PMS.

Unfortunately, it failed to add the value we hoped for. What we had not understood was how much of a system of record is not features. It is twenty years of edge cases, accounting treatments, regulatory requirements across multiple states, integrations with vendors we did not control, and a thousand small behaviors that only reveal themselves at scale. We were rebuilding a commodity, to end up where we already were.

The lesson took about a year to learn and I would give it to anyone for free. It is far easier to work with the system of record than to replace it.

The way I think about it now is 80/20. Roughly 80% of what any multifamily operator runs on is the same as what everyone else runs on. Leasing, maintenance, resident communication, accounting. That software is mature and widely available, and buying it involves trade-offs but very little differentiation. Nobody has ever won on the 80%.

The 20% is different. That is your capital structure, your lenders and covenants, your entity hierarchy, your investment vehicles, your underwriting, your operating preferences, the way you actually run the business. It is specific to you, it is where the edge lives, and it is the part nobody sells you, because there is no market for a product with one customer.

We spent a year trying to rebuild the 80%. We should have spent it on the 20%.

Some believe this ends with everyone building their own stack, but I do not believe in that. Life is easier in the club than out of the club. Buy the 80%. Insist on getting your data out of it. Build the 20% yourself.

The question nobody can answer

An LP will spend months on a sponsor before committing capital. Track record, market thesis, deal pipeline, alignment, the team, references from three funds ago. All of it rigorous, and all of it aimed at the sponsor's judgment.

Almost none of it is aimed at where the numbers come from.

Ask a straightforward question at any point in that stack: how did the figure in this quarterly report get here, and what happened to it along the way? In most cases the honest answer is that a property manager ran a report, somebody at the asset manager reformatted it, somebody at the fund manager reformatted it again, and each of those steps was done by a person under deadline with no record of what they changed. The number arrives at the LP having been retyped three times, and nobody in the chain can reproduce it.

That is not fraud and it is not incompetence. It is the accumulated result of everything above. But it means the reporting an institutional investor relies on is, at the end of a long game of telephone, unauditable.

This is starting to matter commercially. GPs are being asked for more granular reporting on shorter cycles, and the ones who can produce it on demand are separating themselves from the ones who assemble it by hand every quarter. I expect data provenance to become a diligence question the way cybersecurity did about ten years ago. It will start as an unusual request from one sophisticated allocator, and then it will be on every questionnaire.

The sponsors who have their own data will answer it in an afternoon. The ones who do not will discover, in the middle of a raise, what their reporting is actually made of.

Demand your data

Everything to this point is diagnosis. Here is the part you can act on this quarter.

Your data lives in two places, and each one takes a different ask.

Your property manager holds the operational record. That relationship is governed by a management agreement, which means you have a contract to work with. Most property management agreements were written when the deliverable was a binder. They specify a rent roll, a T-12, an operating statement, and a delivery date. They say almost nothing about structured access to the underlying records, and that silence has always favored the incumbent.

Four terms belong in your next PMA.

• Ownership. All data generated at the property is yours. Your manager holds it as custodian. The fact that it sits inside a third-party system does not change that.
• Structured access. Machine-readable delivery on a defined cadence, to you or to a platform you designate. A monthly PDF does not satisfy this. Neither does a spreadsheet an analyst assembled by hand.
• Definitions. Written documentation of how they calculate occupancy, gross potential rent, market rent, concessions, and delinquency. This costs your manager almost nothing and it is the difference between comparable data and six sets of numbers that only look alike. If you run multiple managers, this clause alone will pay for the exercise.
• Exit. A complete structured export within thirty days of termination, with the same documentation. This is the term owners think about least and get hurt by most.

Your software vendor holds the system. There is no contract for you to lean on here, because in most cases you are not the licensee. What there is instead is demand, and it works slowly but it works. Ask the question in every renewal conversation and every RFP. Make owner-provisioned data access a scored line item when you evaluate systems. Ask your manager what it would take, and ask them to ask.

Pay attention to the answer. A manager who cannot get you your data is telling you something about their systems. A manager who will not is telling you something about the next five years of the relationship.

Demand your data, or move systems and/or managers.

What we built

I did not set out to be in the software business. We built what we built because nobody would sell it to us.

That work became Playgrounds. It is the 20%. It sits on top of whatever systems of record you already run, and it does not try to replace them. Underneath it is the thing that took us years and most of the pain in this paper: your data, out of your systems, modeled, unified, and current.

We can do that part for you. Getting an owner's data out of a property management system, off spreadsheets, and into a shape a business can actually use is not a product you install. It is work, and we have done it at our own expense, on our own portfolio. We can come in as your team and do it on your systems, whatever they are.

Then you build. Entity structures, capital stacks, lender and covenant tracking, market research, underwriting, pipeline, asset management against pro forma, reforecasting, budgeting, construction, revenue management. All the things no vendor will build for you because there is no market for a product with one customer. Your operators build them, not a development team you have to file a ticket with.

We can do this because we are not a software company that discovered real estate. We have been the owner, the property manager, the construction manager, the asset manager, and the fund manager.

If your data is a mess, that is the normal starting condition and it is the part we are best at. Start there.

If you have already done the hard work and your data is in good shape, you are further along than most of this industry and you should skip straight to the interesting part. Point us at your warehouse, bring the models and the code your team has already written, and build your operating system on top of it.

The club has to modernize

A word to the property management systems, who I assume will read this too.

Being in the club should not mean you cannot hold a copy of your own records.

There is a version of the next few years where the systems of record stay closed and treat data access as a licensing line item. I understand the logic. An owner who cannot leave is an owner who renews. But that logic has an expiration date on it, because a platform you cannot extract from is a platform you are already planning to replace. Every year of that builds pressure toward a rip-and-replace that nobody wants and everybody eventually does.

The other version is better for the vendors, not just for us. A system that opens up stops being something owners tolerate and becomes something they build on. Nobody replaces plumbing. They extend it. The first major platform to ship real owner-provisioned, structured data access will take share from the ones that do not, and the cost of shipping it is trivial next to what it protects.

I think the good actors in this ecosystem already know that. Some of them are already moving.

As for the rest of us: every conversation in this industry right now is about AI, and almost none of them are about the thing that decides whether any of it works. A model is only as useful as what it can see. Right now, most owners cannot see their own portfolio without a person in the middle rebuilding the answer by hand.

That is the constraint. Not the technology, which is available to everyone and getting cheaper every quarter. The constraint is access to your own information, and it is the one problem in this business that nobody is going to solve on your behalf.

We spent years learning that. You can have it in an afternoon.