Why Stitching Together Technology Companies Doesn't Work

It’s 9:07 on a Monday morning. As the Head of Innovation for a large commercial real estate portfolio, you’re used to things changing in an instant.

This morning, one of the PropTech companies you were evaluating for portfolio-wide adoption has announced that it’s being acquired.

It might be a good thing, it might be a bad thing. All you know for certain is that you need to take a step back and do an information gathering exercise to understand the plans for the product and company you spent so much time getting to know.

On the other hand, it offers an opportunity to reflect on the goals for technology adoption in general. One of your most important mandates is to get full coverage of your business needs with as few technologies as possible.

You’ve learned that there’s no platform that does absolutely everything, so it seems like the recent wave of acquisitions is a net positive, a trend towards fewer platforms covering more ground.

Maybe, by tracking which companies are making the most and biggest acquisitions, you can project out who will arrive to that “one platform to rule them all” the soonest.

At the same time, there’s a nagging suspicion that the reality of piecing distinct solutions together into a working whole is more difficult than the press releases let on.

What is technology, really?

The truth is that acquiring companies for the purpose of stitching their technology together is very difficult to do successfully.

It doesn’t take a veteran software developer to understand why. All it takes is a sober look at what software is made of.

Basically any platform can be broken down into four components: the code, the logic, the database, and the API.

On the most basic level, it’s difficult to stitch together platforms because they’re often written in different coding languages. You can’t copy-paste the code for the same reason that you can’t copy-paste a paragraph of Spanish into a book written in English.

Even if you could, it just wouldn’t line up. Each of these four components are tightly dependent on each other. The smallest changes in one place will have unforeseen downstream effects.?

Vision vs reality

There has already been $18 billion spent on mergers and acquisitions in the PropTech space in 2021 alone.

Clearly there is faith that with enough market share, the “devil in the details” problem goes away.

The reality is often exactly opposite.

That’s because the decisions that created the tight and complex connections within a software platform were often made years ago. And the people who made those decisions may not still be around, or just as often, do not come over in the acquisition.

If that happens, the technology tends to ossify.?

That’s because there are business needs that take precedence. Users are currently relying on the solution and no one wants to disrupt them by breaking things to create a more integrated and seamless experience.

It’s like purchasing two high rise towers on the same block and saying: “Okay, now make them one building.” Oh, and the original architects and development teams can’t be consulted. Also, tenants are going to expect to have access to their spaces the whole time.

It would be easier to knock them down and build from scratch. Software ends up being the same. Sometimes, access to the source code is no more help than seeing how the front end works and re-engineering it on the backend.

Because of this, what’s often actually happening after an acquisition is a consolidation of distinct products under one corporate umbrella, rather than a seamless software experience.

The alternative

There is nothing inherently wrong with acquisitions. But it is important to not assume that an acquisition will necessarily lead to an integration of the underlying technologies.

An alternative approach is a “homegrown” platform, one that was built entirely in-house.

The downside is that it generally takes longer to build out a comprehensive platform offering. On paper, it’s much faster to buy than it is to build.

But like the tortoise and the hare, speed isn’t the only factor in winning.

The trick is knowing what to look for when evaluating technology. Here are some questions to consider asking:

1. Are the different “modules” all in one login and URL/domain? Is the login the same for the mobile and web app experiences?
2. Is there an API? Is it used internally?
3. Tell me about the evolution of the product

The answer to the first two should be an easy “yes.” The last question should help illuminate how strong the backend architecture is. For example, if the evolution is adding new features within the same basic framework, that doesn’t tell much.

However, if it’s clear that the platform is using the same data in multiple places and/or use cases, that’s a good sign that it was built to be “extendible,” meaning built to serve future needs without necessarily knowing what those needs are.

At the end of the day, it’s unlikely that any homegrown platform, or platform built through acquisitions', will be able to do absolutely everything. A better approach is to segment operations into themes, such as “front of house” (everything tenant facing) and “back of house” (everything related to physical assets) and make sure there is a bridge between platforms that cover large segments of the business.

We're proud of the platform we've built here at Enertiv and encourage you to schedule a demo. Even if you've seen it more than 6 months ago, it's worth seeing the new capabilities.