What eight years on one codebase taught us about M&A

An acquisition is decided in the codebase long before it is decided in the data room. The engineering choices a team made years earlier are what let an acquired product survive the deal, or what force the rewrite that quietly erases the value the buyer paid for.

We know this from one product. We built dashCMA for its founder, Karen Abram, starting in 2018. Inside Real Estate acquired it in 2020 and kept us on as the engineering team. We are still building it today, now as CORE Present. Eight years, one codebase, across a change of ownership.

Most of what is written about mergers and acquisitions comes from the boardroom. This is the view from the engineering team that lived through one: what carried the product across the acquisition, and what would have sunk it.

Key Takeaways

• Most acquisitions disappoint, and the usual failure is integration after the signatures, when the institutional knowledge walks out with the people.
• The engineering decisions that survive an acquisition are made years earlier, in clean interfaces that let a product move to new data without a rewrite.
• We built dashCMA in 2018, carried it through acquisition by Inside Real Estate in 2020, and still build it as CORE Present today.
• Continuity is a property of the team and its standards, and it survives any individual leaving.

Most do. Studies put the M&A failure rate between 70% and 90%, by Harvard Business Review's 2011 analysis The New M&A Playbook. The target is rarely the problem. The failure comes in integration, after the signatures.

A large part of that failure is people. Executives and senior staff at acquired companies leave at well above normal rates, and the elevated turnover persists for years (Jeffrey Krug, Harvard Business Review). When they go, they take the things no document holds: why a system is built the way it is, which parts are load-bearing, what already failed and why.

For a software product, most of that is engineering knowledge. So the question that decides whether an acquisition keeps the value it paid for is a simple one. Does the team that knows the code stay?

The single decision that carried dashCMA through its acquisition was made in 2018, two years before anyone discussed a deal. We built the product around its own internal model of what a listing is, and kept every connection to outside data behind an interface we owned.

dashCMA pulled its listing data from one regional MLS provider. Rather than let that provider's shape spread through the code, we transformed its data into our own format at the boundary. The slide engine, the pricing logic, the API, and the frontend only ever saw our model. Every interaction with the outside provider sat behind that one interface.

When Inside Real Estate moved the product onto its own nationwide data in 2020, that boundary paid for itself. Integrating the new source meant writing one transformer and one connector that satisfied the existing interface. The slide engine, the pricing logic, and the agent UI did not change. It was additive work, and close to none of the existing code moved.

The pattern has a name: an anti-corruption layer. You keep the outside world's shape at arm's length, behind an interface you control, so swapping what sits on the other side stays cheap. A habit that looked like ordinary care in 2018 turned a post-acquisition data migration into an afternoon's worth of additions.

This is the same discipline that lets you rebuild a live platform without downtime: clean seams, drawn early, are what make later change safe. The work that survives an acquisition is rarely heroic. It is decided long before the acquirer shows up.

You connect it at clean seams and leave it its own product. CORE Present never dissolved into the parent's systems. It kept its own codebase and joined the Inside Real Estate suite at two seams: identity and data.

The rest was sequencing. We built CORE Present from 2020 and launched it in the spring of 2021. dashCMA kept running for its existing customers until their contracts expired, and we phased it out by the end of 2022, moving those customers onto CORE Present. Two products ran at once for a while, which is the safe way to retire one.

You do not have to absorb an acquired product into the acquirer's systems to make it part of the family. Connect identity and data at interfaces you control, and the product keeps its own shape and its own pace.

Compounding. The same team carried dashCMA from a regional pricing tool to CORE Present, a national platform now used by more than 350,000 real estate professionals across more than a million client presentations.

Each transition built on the last because the team carrying it never reset. The acquisition, the move from a pricing report to a full presentation platform, the four-level brand inheritance for enterprise brokerages, the enterprise rollout to tens of thousands of agents: each one started from everything the team already knew. A new team would have spent its first year relearning the codebase the old one wrote.

The full arc, from a founder's pricing tool to a platform across the major national brokerages, is in the CORE Present case study.

People can move on. Continuity is carried by the team's standards and its shared understanding of why the system is built the way it is, and those outlast any individual. The faces can change. The approach and the reasons behind the code stay with the team that holds it.

Every buyer of an embedded team has the same fear: what happens when the one person who understands the system leaves. The honest answer is that the knowledge lives in the structure of the code and in standards the whole team holds, so it survives any single departure. Eight years without a re-platform, across an acquisition and a rename, is what that looks like in practice.

So continuity is an engineering property before it is a staffing one. A codebase built to be understood, with clean boundaries and standards the team shares, is one a team can carry across an acquisition, a rename, and years of scaling. That is the work we do as an ongoing engineering partner: staying with a product long enough that the knowledge never has to be rebuilt from scratch.