The big shift in AI and real estate isn’t new software

When we started our property company, we set ourselves a clear goal: run the operation as efficiently as possible and stay near the front in how we put new technology to use. Among other things, that meant digitising the processes where doing so actually created value: documentation, management, workflows, and other parts of daily operations.

So we did what was natural at the time. We looked for the best systems we could find and started buying them.

The problem was that we quickly ended up with a lot of different systems. Some were good. Others were not. Together, they never became the efficient whole we had imagined.

Above all, we knew fairly precisely how we wanted to run our operation. We had our processes, our needs, and features we wished the systems had but that simply weren’t there. The software was, understandably, built to work for many different property companies, not exactly for ours. We knew our operation better than any of the systems did.

In the end, we kept the systems that genuinely worked, along with anything that sat outside what we could reasonably build ourselves. The rest we cancelled. Instead, we started building our own systems, workflows, automations and agents, shaped around how we actually run our buildings.

AI pilots in real estate

Real estate has long had a reputation for being slow to adopt new technology. On paper, at least, that seems to have changed. JLL’s 2025 Global Real Estate Technology Survey, covering more than 1,500 senior decision-makers across 16 markets, shows that 88% of investors, owners and landlords have started piloting AI, compared with 5% in 2023. On average, companies are working on five use cases at once. These include document management and lease handling, tenant service and work-order management, energy optimisation, portfolio analytics, and due diligence.

And some of it delivers results. Sensor networks, data-modeling tools and predictive-maintenance systems have been adopted by over 80% of large occupiers, according to the same JLL research. In energy, a documented pilot in Toronto with GWL Realty Advisors reported 25–29% reductions in HVAC energy consumption. The figures come from the vendor, but the results are at least tied to actual, named buildings.

Fitting AI into daily work

But piloting AI is not the same as creating value. In the same JLL survey, only 5% of companies report having reached all the goals of their AI programs. Most initiatives are still at the experimental stage and haven’t been scaled up to any meaningful degree. At the same time, more than 60% of investors describe themselves as unprepared, technically and strategically, to adopt AI at full scale, according to reporting on the survey.

The same pattern shows up outside real estate. MIT’s much-cited GenAI Divide report concluded that 95% of enterprise AI pilots produced no measurable P&L impact, despite an estimated $30–40 billion in investment, as reported by Fortune. The study’s methodology has been contested, so it’s wise to be careful about drawing sweeping conclusions from a single number. The problems rarely seem to have been the AI models themselves. They appeared when the technology had to be integrated into how the business actually works. Generic tools handled simple tasks but ran into trouble when workflows demanded more business context, as Forbes noted in its analysis of the report. The systems that created value were the ones more deeply integrated into the company’s actual processes.

At the same time, one finding in the MIT report runs directly counter to what we chose to do: tools from external vendors succeeded roughly twice as often as internally built solutions.

One important difference is what the study actually measured: enterprise IT projects, where systems were built for business processes that the people building or commissioning them didn’t necessarily work in themselves. That is a very real problem with internal system builds.

But our situation looks different. We build the systems for our own operation. We know the process, we use the systems ourselves, and we notice immediately when something doesn’t work as it should. The person who knows what an inspection protocol needs to contain can also decide what the system should require before a control can be closed.

Whether that advantage holds equally well for other businesses, we don’t know. But we know what it has meant in our own operation.

The cost of building your own software

There is one change that matters more than which individual AI use cases happen to work right now: building software has become dramatically cheaper and simpler.

The numbers around AI-assisted building should be taken with some caution. Much of it is self-reported by the companies involved, and high growth figures don’t necessarily say anything about durability over time. Lovable, one of several platforms in the space, reports having passed $500 million in annualized revenue, with around a million new projects created every week, according to TechCrunch. Users are increasingly building their own internal tools: CRM systems, inventory systems, HR platforms. The kind of software companies were previously all but obliged to buy off the shelf.

Klarna is a well-known example of the same development. In 2024, the company announced it would move off Salesforce and Workday and replace parts of those systems with internally built, AI-supported solutions. Later reporting showed the picture was more complicated: parts were replaced with other SaaS services rather than pure in-house builds, as CX Today reported.

Building in-house had become realistic enough for Klarna to reconsider what it bought, even if the result still included other SaaS products.

For us, running a small property company, the change is even easier to see. Only a few years ago, a bespoke internal system would have required developers, a substantial budget, and a project that would have been hard to justify for an operation our size. AI-assisted development tools have changed that calculation. Building your own is now a realistic option for an operation with fifty apartments, not just an organization with fifty thousand.

Designing around your own operation

Software sold to an entire industry can never be built exactly around how one individual company works. There is nothing strange about that. A vendor has to build a product that works for many different customers, with different buildings, organizations and ways of working.

That is exactly what we experienced. We could find systems that solved parts of what we needed, but nothing was built precisely around how we wanted to run our operation.

The difference today is that we no longer have to accept that limitation in the same way. If you truly know your own operation, you can start building the systems around it: which controls actually need to be performed in your buildings, what documentation needs to exist, and how the maintenance of individual components should be tracked over time.

But easier to build does not mean the work itself has become easy. To build a good system, you first have to understand the process you are building into it. You have to know which controls need to be done, when they need to be done, and what documentation is required. You also need to have your data in order.

Our first version was wrong. So was the second. But when building has become this much cheaper and faster, it has also become possible to test, discover what’s wrong, and rebuild, without every iteration turning into a major IT project.

Three versions of our operations system

We built our own operating system for the properties we run. It took three versions to get from our first attempt to the system that is now secure, deployed and used in our daily operations. In total, we spent roughly 200 hours building it.

Much of what we learned came from getting it wrong first. Not just which features the system needed, but how the structure itself had to work for the information in it to be trustworthy.

Once the third version was in real use, we got a very concrete measure of what that structure was worth. A component inventory of two of our properties took about 40 minutes and surfaced 4.2 million SEK in deferred maintenance that wasn’t in our previous maintenance plan.

That doesn’t mean the old plan was poorly made. The difference was structure. When every component, interval and action exists as structured data, you can see connections and gaps that are much harder to spot in an ordinary document.

That is where RENAVID comes from.

The system was our first build, but not the last. Since then, we have kept investigating, testing and building new systems in our own property operation. Some are still in use. Others we have thrown away.

That work is the raw material for everything RENAVID does. We document what we build and why we build it the way we do, what works and what doesn’t, so that other property operators can build their own.