Technology due diligence is an operating decision, not a transaction checklist

Start with the investment thesis, not the architecture

The first diligence question should not be whether the stack is modern. It should be whether the current technology can support the forecast revenue, margin and customer growth without disproportionate or undisclosed investment.

That question places technology underneath the business model. If the plan assumes rapid customer growth, diligence must examine whether infrastructure, product architecture, delivery capacity and support operations scale with it. If the plan assumes Gross Margin expansion, the technology cost base must show how. If the investment case depends on product integration or shared data, the systems must make that technically and legally possible. If the plan assumes improved EBITDA, technology synergies must be more concrete than a line in a spreadsheet.

Architecture quality matters. But investors do not buy architecture diagrams—they buy the business the architecture must enable.

The useful test is therefore not “Would I design this system the same way today?” It is “Can this system carry the intended business, at the required risk and cost, for the relevant period?” That includes hidden CapEx, continuing OpEx, migration effort, delivery constraints and the cost of keeping customers stable while the company changes.

This perspective also prevents diligence from becoming a beauty contest. A clean cloud-native diagram does not prove viable unit economics, strong ownership or dependable delivery. A less fashionable system may support profitable operations, loyal customers and manageable change. The business plan—not technical taste—provides the standard of materiality.

Legacy is not the red flag; economic constraint is

A technically unattractive system can still be an excellent business asset. A modern stack can still be expensive, fragile or poorly owned.

Legacy becomes material when it deteriorates economics, blocks growth, creates unacceptable resilience or regulatory exposure, concentrates knowledge beyond a manageable level, or removes strategic options. Until then, changing a profitable system merely because its architecture offends current taste can destroy value rather than create it.

A legacy stack is not automatically a deal risk. An architecture that cannot support the business plan is.

The same discipline applies to technical debt. Some debt is deliberate: a company accepts a shortcut to reach the market, learns from customers and retains a realistic path to refactoring. That can be a rational allocation of capital. Dangerous debt is different. It creates a technical dead end, makes each change disproportionately expensive, blocks scaling, produces material security or legal exposure, or turns future change into an economically irrational proposition.

Technical debt becomes an investment problem when it starts constraining economics, scalability or strategic options.

Diligence should therefore identify both the debt and its consequence. Which revenue assumption does it restrict? Which customer promise does it endanger? Which cost grows faster than the business? Which product or integration option does it remove? What would remediation cost, when would it be needed, and what risk remains in the meantime?

This is closely related to the decision between modernization, re-platforming and rebuilding. A complete rebuild is not a moral correction for an old system. It is one investment option with its own transition risk, customer risk and opportunity cost. The evidence-based choice is explored further in Modernize, re-platform or rebuild: what evidence should decide?.

Put technology economics inside diligence

Technology diligence should ultimately resolve into business economics. That requires more than an infrastructure invoice or an engineering budget.

The cost model may include hosting and infrastructure COGS, SaaS licenses, third-party APIs, AI inference, engineering capacity, the internal and external delivery mix, vendor commitments, migration costs, support burden, security or compliance remediation, technical-debt repayment and integration effort. It should also expose manual work hidden behind apparently automated processes.

None of these costs is inherently good or bad in isolation. Cloud spend is not a problem if revenue and Gross Margin scale faster. It becomes dangerous when unit economics deteriorate with growth, when the company cannot attribute spend to products or customers, or when the architecture demands increasing cost merely to preserve the same service. The objective is not minimum absolute cost. It is sustainable technology economics.

The same applies to engineering capacity. A large team may represent productive investment, or it may be compensating for fragile architecture and manual operations. A small team may be efficient, or dangerously dependent on a few people. Diligence has to connect capacity with roadmap delivery, maintenance, support and the changes implied by the business plan.

AI makes this connection especially visible. An AI feature that improves the demo but destroys unit economics is not technological differentiation. Inference costs, evaluation, monitoring, failure handling, data preparation, model changes and operational ownership belong in the lifecycle cost. A feature can be technically impressive and still weaken Gross Margin.

Synergy assumptions need the same scrutiny. Tool consolidation, reduced duplicate SaaS spend, shared infrastructure or common platform services can be realistic. A complete merger of two different core platforms in a few months is usually a different class of risk. The investment case must distinguish a plausible saving from a transformation program that has not yet been designed or funded.

Every material technology finding should eventually resolve into one of three things: a business constraint, a quantified investment requirement, or an execution priority. Otherwise it remains an observation rather than decision support.

Assess delivery capability, not engineering theatre

“We are agile,” “we have CI/CD,” and “we have high test coverage” describe practices, not necessarily outcomes.

Useful diligence evidence asks how work really moves through the company. Deployment Frequency, Lead Time for Changes and Change Failure Rate can reveal delivery behavior when definitions and context are clear. Commit-to-production time shows whether the nominal pipeline actually removes friction. Onboarding duration helps expose whether knowledge is accessible. Bus Factor shows where continuity depends on individuals. Cloud spend relative to revenue can illuminate scaling economics when the underlying business model makes the ratio meaningful.

None of these measures should become a universal score. Test coverage without quality context can reward tests that prove little. Story Points are local planning units, not company productivity. Backlog size may reflect demand, indecision or poor maintenance. Lines of Code say almost nothing about business capability.

The purpose is to build a coherent operating picture. Can teams release small changes safely? Can incidents be diagnosed and repaired? Can new engineers become productive without oral tradition? Does roadmap throughput match the forecast? Are the people who own a service also able to operate it?

Two informal questions can reveal more than polished documentation: Which subsystem worries you most at two o'clock on a Sunday morning? And: What happens if a particular developer leaves tomorrow? The specificity of the answer often shows whether management understands its own risk.

Delivery capability also determines remediation credibility. A target may identify the correct architectural changes, but a plan is not credible if the organization has never demonstrated that it can deliver comparable change while maintaining customer service. Diligence should assess not only what needs to be done, but whether this team, operating model and governance can do it.

Team, ownership and rights can outweigh architecture

A strong team can repair weak architecture. A weak ownership culture will eventually degrade even good architecture.

Key-person dependency is serious, but it can often be managed through retention, succession, documentation and knowledge transfer. An organization in which nobody owns the system is harder to repair. If responsibilities are diffuse, incidents move between teams, architectural decisions have no accountable owner and maintenance is consistently deferred, the risk is systemic rather than personal.

Technology ownership also has a legal dimension. Diligence must establish whether the company has the right to use, modify and transfer the technology on which its business depends. IP assignments, open-source obligations, third-party licenses, vendor contracts and data rights can be more material than an imperfect module boundary. In mature companies, history makes this work harder: products, contributors, contracts and corporate structures change, while the evidence chain must remain intact.

Data and privacy require equally operational questions. Are tenants separated? Are access-control lists and permissions preserved across systems? Where does data flow? What changes if two companies pool data after closing? Does the proposed integration remain compatible with contractual purpose and GDPR obligations? A technically simple data combination can be legally or operationally impossible.

Security diligence should focus less on whether any vulnerability exists—one almost always can—and more on how the organization responds. Patch discipline, incident response, DevSecOps ownership, remediation speed and post-mortem culture show whether risk is managed as an operating capability. Certifications can support the evidence. They cannot substitute for it.

This is why the target CTO should not defend the architecture as if diligence were a courtroom. The CTO should explain reality transparently, connect material risks to cost and business impact, and show a credible remediation path. The objective is not to make the technology appear perfect. It is to demonstrate that management understands what exists and knows how to operate it.

AI changes the diligence model

AI claims require technology diligence to examine product value, data, governance, failure modes, unit economics and lifecycle cost together.

The first question is whether the capability creates defensible product value or merely presents a thin interface over a provider available to everyone. If differentiation depends on data, diligence must ask whether reliable Ground Truth exists, whether the company may use it for the intended purpose, and whether it remains useful when products or processes change.

Permissions cannot disappear at the AI boundary. Retrieval and generated output must preserve tenant separation, access controls and source-system entitlements. Training-data rights and output ownership need clarity. Sensitive information must not leak through prompts, logs or model behavior. Provider changes, model retirement and vendor lock-in require a credible response.

Failure economics are as important as model quality. What is the consequence of a hallucination? Which outcomes can remain probabilistic? Where must deterministic controls or human approval remain? How much expert review survives the automation? How do inference and evaluation costs change with usage?

These are production questions, not objections to AI. They distinguish a feature that can become a dependable business capability from a demonstration that transfers cost and risk into operations. The decision framework is developed in When industrial AI should not ship.

A finding needs a post-closing destination

A diligence finding should not disappear into a PDF after closing. It should have an owner, business impact, cost, timing and decision.

Some findings belong before signing. Unresolved IP ownership, a material regulatory blocker, a technology cost model fundamentally inconsistent with the plan, an architecture unable to support the investment thesis or a critical integration incompatibility may affect valuation, deal structure, conditions, contractual protection or the investment decision itself.

Other findings belong in a 100-day plan or longer transformation roadmap: refactoring, security hardening, FinOps, vendor consolidation, process harmonization, finance or ERP integration and product-roadmap changes. The distinction matters. Treating every imperfection as a pre-signing blocker creates noise; deferring a thesis-critical constraint until after closing creates avoidable surprise.

The strongest diligence work already suggests what must happen next. Where technology synergies are fundamental to the investment thesis, a high-level target direction may be necessary before closing. Detailed target architecture should normally follow deeper operational understanding. Premature standardization can destroy the target's agility; indefinite separation can preserve duplicate cost and prevent synergy. The right pace depends on whether the business is intended to remain stand-alone, how the product strategy evolves, how platforms are expected to connect and what customers can safely absorb.

Customer continuity is a technology decision as much as a commercial one. Data migration, login or SSO changes, billing migration, API shutdown and product retirement can alter a customer's workflow and trust. Infrastructure, stability, performance and security can often improve early without visible disruption. Forced migration and interface change deserve greater caution.

High customer satisfaction can itself become an integration constraint: a migration that looks efficient on an architecture diagram may destroy more value than it creates.

The deal creates operating value only when the combined company can perform better than the businesses separately—through lower cost, higher revenue, better customer experience, stronger product capability, useful data, faster time to market, improved EBITDA or lower complexity. Technology diligence should test whether those improvements are real, compatible and fundable.

Due diligence changes when you know you will still own the consequences after closing. You stop hunting for architectural imperfections and start looking for the decisions that matter on day one.

Five questions that move the investment discussion forward

These questions are not a substitute for diligence. They force the technology discussion back into the investment case:

• Can the existing technology support planned growth without uncovered or disproportionate capital requirements?
• Which specific technology synergies are included in the EBITDA case, and what must be true for them to materialize?
• What are the real hosting, third-party API and license COGS per relevant customer, transaction or product unit?
• Where are the critical Bus Factor and key-person risks, and how are ownership and continuity managed?
• What is a realistic cost and time frame for post-merger integration without damaging customer continuity?

The value of these questions is not the immediate answer. It is whether management can produce consistent evidence across architecture, finance, delivery and customer operations.

Five things a target CEO or CTO should prepare

Permanent diligence readiness is ordinary operating discipline, not transaction theatre:

• Disclose technical debt and connect it to cost, business impact, timing and remediation.
• Put IP rights, open-source obligations and material vendor contracts in order before diligence begins.
• Maintain credible hosting, FinOps and delivery evidence rather than reconstructing it under deal pressure.
• Understand and document data architecture, GDPR exposure, data flows and authorization models.
• Explain how the architecture supports—or must change to support—the next phase of the business instead of defending it as perfect.

Architecture documentation, ownership, contracts, cost structures, delivery signals, security evidence and roadmap decisions should be current because the company needs them to operate. A data room assembled under pressure is a weak substitute for management information that already exists.

Exit readiness is not a transaction project. It is a side effect of running the company well.