What Building the Systems Teaches You About Buying Them

Why technical architecture matters in M&A and technical due diligence, and what buyers can learn from the people who build the systems they're acquiring.

A company can own a proprietary platform without owning much technology. It can have thousands of pages of content without having a functioning knowledge asset. It can describe an AI capability that largely disappears when the underlying vendor changes. It can have sophisticated software whose most important business logic lives in a few people's heads.

And it can call all of these things assets.

A buyer has to ask a different question: what, exactly, are we buying?

That question sits underneath technical due diligence. It is also a question we have been asking for years from the other side of the transaction, while designing, rebuilding, replacing, and integrating digital systems for businesses.

The vocabulary changes when the conversation moves from architecture to M&A. The diagnostic discipline does not.

The founder sees a platform. The buyer sees rebuild cost. That difference is easy to miss when looking at a company from the outside.

BUYER SEES BUILDER LEARNED

What a Buyer Sees That a Builder Has Already Learned

A founder naturally sees everything the company has accumulated: the platform, the workflows, the content, the integrations, the internal tools, the people who know how everything works. A buyer has to see something else. What would still exist if the company changed hands tomorrow. Which capabilities are genuinely transferable. Which dependencies come with the business. Which parts would have to be rebuilt. And which things that look like assets are actually services rented from someone else.

This is why technical architecture can matter in M&A even when the transaction itself is not primarily about technology. The question is not whether the company uses modern software, but how much of its real capability the company actually owns.

WHY IT MATTERS

Why Technical Architecture Matters in M&A Due Diligence

Financial due diligence and legal due diligence answer essential questions. Revenue. Contracts. Margins. Liabilities. Ownership. IP assignments. Corporate structure. Those disciplines are designed to verify exactly those things.

Technical due diligence answers a different category of questions. Is the technology genuinely proprietary. Is a "custom platform" actually custom. Which systems are critical to operations. Which vendors could materially affect the business. Where does the company's data live. What happens if a key provider changes its pricing or terms. Can the system be operated without the people who originally built it. How much would it cost to replace the critical components.

These aren't questions about whether the code is elegant. They are questions about what technological reality sits underneath the business being acquired. Someone who has actually built comparable systems approaches these questions differently, because they have encountered the same problems before, while trying to make the system work, rather than while reviewing it after the fact.

WHAT COMPANY OWNS

What Does the Company Actually Own?

A technology stack tells you what a system uses. It doesn't necessarily tell you what the business owns.

Consider a company that describes its customer platform as proprietary. The obvious questions are technical: is it Laravel, React, AWS, PostgreSQL, something else. Those details matter, but they are not the first question. The first question is what business capability does this system actually provide. Then, which part of that capability is proprietary, which parts are commodity infrastructure, which dependencies could be replaced without materially changing the business, and which dependencies would create significant operational risk if they disappeared.

This is familiar territory to anyone who has designed a system properly. Before deciding what to build, you decompose the business requirement. Before deciding what a buyer is acquiring, you decompose the claimed capability. The technology stack is only the beginning.

BUILT VS RENTED

Built vs. Rented: Finding the Real Proprietary Layer

Every serious architecture contains things that are owned and things that are rented.

What Businesses Actually Own vs. Rent

There is nothing inherently wrong with renting technology. Renting commodity infrastructure is often the correct build-versus-buy decision. The problem appears when a business describes rented capability as proprietary differentiation. A polished interface can make a commodity platform look custom. An internal name can make a SaaS product sound proprietary. A custom integration can make a collection of external services look like a single owned platform.

The question is not whether those things are useful. The question is which layer actually creates the capability the buyer is paying for.

KNOWLEDGE ASSET

When Digital Knowledge Becomes an Asset, and When It Doesn't

The same problem exists outside software. Businesses accumulate knowledge. They produce content, documents, research, training materials, internal processes, customer information, specialized expertise, and years of historical work. On paper, the inventory can look enormous. But inventory is not the same thing as an asset.

We once worked with a knowledge-heavy business that had accumulated a substantial digital library over many years. There was no shortage of material. The problem was what happened when we examined the material as a system. Some of the material was technically present but functionally disconnected. Some valuable knowledge existed in documents that were difficult to discover or connect to one another. Some expertise was obvious to people inside the business but almost invisible in the structure through which the outside world encountered it.

The business had accumulated information faster than it had built a system capable of representing it.

That distinction is important far beyond search. A buyer might see "the company has a substantial knowledge base." A technical review needs to ask how much of that knowledge is actually structured, transferable, discoverable, and capable of producing durable business value. A document sitting on a server is not automatically a digital asset. A page receiving impressions is not automatically an audience. A database containing information is not automatically an intelligence layer.

The asset and the system that makes the asset usable are two different things.

AI FEATURE VS CAPABILITY

An AI Feature Is Not the Same as an AI Capability

AI makes the ownership question even harder. A company can have an AI-powered product without owning the underlying intelligence. It can use an external model, connect it to proprietary data, wrap it in workflows, and present the result through a polished interface. That can be a perfectly legitimate product. But a buyer needs to understand where the differentiation actually lives.

Two products can both have a button labelled "generate with AI." Underneath, they may be completely different businesses. One might simply send a prompt to an external API and display the response. Another might contain proprietary data, retrieval, orchestration, evaluation, domain-specific workflows, and a substantial operational layer around the model. The customer may see the same button. A buyer should not value them as the same asset.

This is why technical due diligence should examine implementation depth, not simply the presence of AI. The question is not does the company use AI, almost every modern digital business can answer yes. The more useful question is where does the company's actual differentiation live, and what survives if the underlying AI provider changes.

FOUNDER DEPENDENCY

Founder Dependency Is a Technical Risk Too

Technology dependency is relatively easy to see. Human dependency is not. A company can have a sophisticated architecture and still depend heavily on one person. The person who knows why the system was built that way, which integration cannot be touched, which customer uses an undocumented workflow, why one process bypasses the normal system, which vendor relationship is actually critical, how a major operational decision is really made.

This is usually described as founder dependency or key-person risk. But the underlying problem is broader: knowledge that has not become organizational capability.

The source code may transfer. The server credentials may transfer. The contracts may transfer. The knowledge may not.

A company can have hundreds of pages of documentation and still have significant key-person dependency. Documentation captures what someone decided to document. It does not necessarily capture exceptions, historical decisions, undocumented dependencies, customer-specific behavior, operational judgment, institutional knowledge, relationships. So the question should not simply be is the system documented. A better question is could another competent team operate, maintain, and evolve this system without the people who originally built it. That is a much more meaningful test of transferability, and transferability is one of the central questions in an acquisition.

COMPLEXITY VS RISK

Technical Complexity Is Not the Same as Technical Risk

Complexity is visible. Dependency is not. A complicated architecture can be modular, documented, monitored, replaceable, understood by several people. A simple architecture can be dependent on one vendor, dependent on one employee, impossible to replace quickly, full of undocumented exceptions.

So technical due diligence should not simply ask how complicated is this system. It should ask how difficult would it be for the buyer to operate, replace, or change it.

A Practical Model for Technical Risk

Dependency × Replaceability × Business Impact

Technical risk rises when dependency is high, replacement is difficult, and business impact is significant.

That is a more useful lens than counting technologies, repositories, integrations, or lines of code.

WHAT TO REBUILD

What Would the Buyer Have to Rebuild?

This is where architecture meets transaction logic. A buyer may not actually be paying for software. They may be paying to avoid rebuilding a capability. Imagine a capability that would take a new team a year or more to reproduce. The value isn't necessarily the source code itself. It may be the combination of software, integrations, data structures, workflows, infrastructure, specialized knowledge, internal tools, customer migration, operational processes.

That is the build-versus-buy equation from the other side of the transaction. The architecture question is should we build this capability or buy it. The M&A question is what would we have to build if we didn't buy this company. They are fundamentally related questions.

There is no universal value attached to a technology stack either. The strategic value of a capability depends partly on who is looking at it. A system that would take years for one buyer to reproduce may be relatively unimportant to another buyer that already has the capability internally, the same logic behind a real buyer universe. This is why technical diligence cannot be separated completely from business context. The question isn't simply what is this technology worth. It is what would this specific buyer otherwise have to build, replace, integrate, or learn. That can include technology. But it can also include knowledge, workflows, data, infrastructure, and organizational capability.

WHAT DILIGENCE EXAMINES

What Technical Due Diligence Actually Examines

A code review asks whether software is sound. Technical due diligence asks what the technology actually means to the business. That means examining at least several layers.

This does not replace financial or legal diligence. It fills a different layer of the picture.

DATA ROOM DIFFERENT WAY

A Different Way to Look at a Data Room

A technology inventory can tell you what exists. It cannot, by itself, tell you what is valuable. The buyer may be acquiring software, but also data, workflows, integrations, knowledge, people, proprietary processes, vendor relationships, operational infrastructure, customer-facing capabilities. And just as importantly, dependencies. The real technical question is therefore not what technology does this company have. It is what capabilities does the company actually control, and what does the buyer inherit when the transaction closes.

A conventional data room tells you a great deal about the company. A technical lens asks you to look for something else. Not simply what does the company say it owns, but what can we verify that it owns. Not how much technology does it have, but which technology creates irreplaceable business capability. Not how many pages, tools, integrations, or AI features exist, but which of them function as durable assets. Not is the system custom, but what would the buyer have to rebuild if it weren't there. And perhaps most importantly, what disappears when the transaction closes.

That is where technical diligence becomes more than a review of technology. It becomes a review of transferability.

VOCABULARY CHANGES

The Vocabulary Changes. The Diagnostic Discipline Doesn't.

We did not start by studying M&A and then look for technical evidence to support an advisory service. The order was reversed. We spent years building systems. We learned where they break. We learned what businesses actually need to own, and what they only need to rent. We learned what happens when a vendor changes its terms. We learned how much knowledge can live inside one person. We learned that a business can accumulate enormous amounts of information without building a system capable of turning that information into a durable asset.

And eventually the connection became obvious. The same questions that determine whether a business should build, buy, replace, or integrate a system are remarkably close to the questions a buyer needs answered before acquiring the business itself.

We didn't start writing about due diligence and then go find evidence. We had the evidence first, years of it, and eventually noticed what it was evidence of.

The vocabulary changes. The context changes. The transaction changes. The diagnostic discipline doesn't.

Why does technical architecture matter in M&A due diligence?

Financial and legal diligence establish critical facts about the company. Technical due diligence examines the technology, architecture, dependencies, data, proprietary capabilities, and knowledge structures underneath the business, a layer neither discipline was built to verify.

Is technical due diligence the same as a code audit?

No. A code audit focuses on software quality. Technical due diligence is broader: it asks what technology contributes to the business, what is proprietary, what depends on vendors or people, and what a buyer would have to replace or rebuild.

Does using SaaS mean a company doesn't have proprietary technology?

No. SaaS can be an entirely appropriate architectural choice. The important question is which capabilities are genuinely differentiated and which are provided by external vendors.

What should a buyer ask about an AI-powered product?

Where does the proprietary capability live. What data, workflows, evaluation, orchestration, or domain-specific logic does the company own. And what remains if the underlying AI provider changes.

Why does founder dependency matter technically?

Because operational knowledge can be part of the system even when it isn't represented in code. If critical knowledge exists only in one person's judgment or memory, the buyer may inherit a dependency that is not visible in an architecture diagram.

Can technical due diligence be useful before an acquisition?

Yes. The same questions are useful long before a transaction: what the business owns, what it rents, where knowledge lives, what would break, and what would have to be rebuilt if a critical dependency disappeared.