Technology Due Diligence: What the Engineering System Reveals

Why Technology Stack Assessment Matters in Due Diligence

For any company where technology carries a meaningful share of the value proposition, and in 2026 that covers most mid-market acquisition targets, the technology stack is both an asset and a liability. A well-architected, maintainable stack accelerates product development, holds down operating costs, and scales with the plan. A legacy-burdened or over-complicated one creates drag on everything the business tries to do.

Traditional technology due diligence leans on three inputs: architecture diagrams, code quality audits, and CTO interviews. All three are useful. All three carry self-reporting bias. The CTO describes the architecture in its idealized form. A code audit samples a small fraction of the codebase. Diagrams show the intended design, not necessarily what is running in production today.

Engineering metadata adds a complementary layer. Commit patterns, build and deployment records, code review dynamics, and incident histories describe how the engineering team actually interacts with the stack, day after day. That behavior reveals more about the stack's health than any diagram of what it is supposed to look like. And it can be read from the structural records the team's tools already keep, without opening the code itself.

The financial stakes are significant. Stripe's research on developer productivity estimated that engineers spend roughly 42% of their time on technical debt and maintenance work: nearly half of capacity spent keeping existing systems alive rather than building new capability. For an acquirer paying a revenue multiple for a technology company, knowing how much engineering time goes to value creation versus upkeep is essential to pricing the asset.

Assessing Engineering Productivity from Metadata

Engineering productivity is notoriously hard to measure directly. Lines of code, commit counts, and story points are all gameable and misleading in isolation. Metadata from the tools engineers already use provides indirect but durable signals.

Commit frequency and distribution. Healthy teams show consistent, distributed commit patterns: many developers contributing regularly, at a rhythm that tracks the sprint cadence. Watch for three warning signs. Highly concentrated output, where two or three developers produce 80% of the commits, points to key-person dependency. Bursty patterns, long quiet stretches followed by frantic end-of-sprint pushes, point to poor planning. A commit rate that declines over successive quarters suggests growing overhead or disengagement.

Pull request dynamics. The lifecycle of a pull request, from creation to review to merge, exposes how the team collaborates. Healthy teams run one or two reviewers per request, review comments that are substantive rather than cosmetic, and merge times inside 24 to 48 hours. Dysfunction looks different: five or more reviewers on routine changes, comment threads dominated by style debates, merges that take more than a week. Rejection rates above 15% usually trace back to unclear requirements or misaligned development practices.

CI/CD pipeline health. Build and deployment records reveal the reliability of the testing and release infrastructure. Build success rates below 85% indicate fragile test suites or unstable infrastructure. Rollback rates above 5% indicate insufficient testing or weak quality controls. Pipeline run times that keep lengthening suggest complexity is growing faster than the investment in tooling. The DORA research program publishes widely used reference points for deployment frequency and change failure rate, which help place a target's numbers in context.

Incident patterns. Production incident frequency, severity distribution, time to resolution, and recurrence rates all belong in a technology health assessment. A company with falling incident counts and improving resolution times is investing in reliability. A company with rising incident counts and flat or worsening resolution times is accumulating operational risk it hasn't priced.

On-call patterns. The distribution of after-hours alerts, and the ratio of escalations to total alerts, shows who carries the operational burden. When a small group of engineers absorbs most of the on-call load, burnout and retention risk follow. When pages increase quarter over quarter, the infrastructure is getting less stable. That cost is real, and it appears nowhere in the financial statements.

Technical Debt Assessment Without Code Access

Technical debt is one of the most material hidden liabilities in a technology company, and one of the hardest to size during due diligence. A comprehensive code audit takes weeks and deep specialist expertise. Proxy signals from engineering metadata correlate strongly with debt levels, and they can be read without opening the codebase.

Maintenance-to-feature ratio. The share of engineering effort going to maintenance, bug fixes, and infrastructure work versus new feature development. As a working threshold, healthy companies keep 60-70% of engineering time on new development and 20-30% on maintenance. When maintenance consumes 40-50% or more of capacity, debt has passed the manageable level. The ratio can be approximated from ticket types and sprint composition in the project tracker, and from the split between bug-fix branches and feature branches in the repository.

Deploy complexity trajectory. If shipping code to production keeps getting harder (more steps, longer builds, more manual verification), the stack is becoming harder to work with. That trajectory is a direct measure of accumulating infrastructure debt.

Hotspot analysis. Repository history shows which files and modules change most often. A healthy codebase spreads modifications across many files. A debt-laden one concentrates change in a handful of hotspot files touched in nearly every sprint: code so fragile that it breaks with any change and needs constant patching.

Test suite trajectory. The ratio of test code to production code, pass rates, and execution times all signal the state of the quality infrastructure. A growing suite with stable pass rates reflects disciplined practice. A stagnant or shrinking suite, falling pass rates, or a habit of disabling failing tests reflects erosion.

Dependency age and update cadence. Libraries and frameworks running several versions behind current are a compounding risk: every deferred update makes the next one harder and widens vulnerability exposure. Commit history around dependency updates shows whether upgrades happen on a rhythm or only under duress.

The practical output for an investor is a maintenance tax estimate: the approximate share of future engineering capacity that existing debt will consume. A company carrying a 15% maintenance tax is in good shape. A company carrying 45% is paying for an engineering team that is half its apparent productive size.

Technology Scalability Signals

A stack that works at today's scale may fail at two times or five times the load. When the value creation thesis depends on growth, scalability has to be assessed before close.

Infrastructure headroom. A company already running at 70-80% of capacity with no clear scaling plan will need infrastructure investment the deal projections may not include. Cloud spend trajectory, database performance trends, and API response times under load all indicate how much room exists before growth forces new spending.

Architecture coupling. Tightly coupled systems, where a change in one area cascades into unrelated areas, scale poorly. The behavioral signature is visible without reading the code: high pull-request conflict rates as developers collide in the same files, long build times because small changes force full rebuilds, and deployment hesitancy, where teams defer releases because any change can break something unrelated.

Team scaling patterns. How output changes as the team grows reveals architectural scalability. In a well-structured system, added engineers produce roughly linear gains. In a poorly structured one, added engineers produce diminishing or even negative marginal output, because the coordination cost of working inside a tangled system outweighs the extra hands. Track per-engineer output across periods of headcount growth to see which pattern holds.

Data architecture maturity. For data-intensive businesses, the way data is stored, processed, queried, and delivered is often the binding constraint on scale. The indirect signals: query performance trends, whether data pipelines complete reliably, and how much of the data team's time goes to fighting infrastructure instead of producing analysis.

Scalability findings feed the underwriting directly. If the stack needs significant re-architecture to support projected growth, that cost (engineering time, operational disruption, opportunity cost) belongs in the investment case. These costs are real, and they're routinely omitted from projections because they're hard to quantify. Engineering metadata supplies the quantification.

Security and Compliance Posture from Operational Signals

A full security audit sits outside the scope of behavioral due diligence. Operational records still reveal a great deal about security and compliance posture.

Access hygiene. Who has access to what, how often that access is reviewed, and whether least privilege actually holds. Deployment and infrastructure activity shows how widely production access is spread across the organization. When a broad set of employees can touch production systems, operational risk runs higher.

Incident response maturity. How quickly and systematically the organization responds when something breaks. The record shows time from alert to first response, how many people mobilize, whether post-incident reviews happen, and whether their recommendations show up in later deployments and process changes. Mature teams close that loop. Immature teams relitigate the same failure every quarter.

Compliance rhythm. For companies in regulated industries, calendar and communication records show the cadence of compliance work: audit preparation, policy reviews, training events. A steady rhythm signals lower regulatory risk than sporadic activity compressed into pre-audit scrambles.

Vendor and third-party dependency. The density and pattern of communication with technology and data vendors shows how dependent the company is on external systems, and how actively those relationships are managed. Deep dependencies paired with minimal ongoing vendor management is supply-chain risk hiding in plain sight.

Posture matters at exit as much as at entry. Strategic acquirers and public-market investors increasingly expect recognized security certifications, real data governance, and demonstrable security practice. A company that needs 12 to 18 months of remediation to clear that bar before exit carries a cost that belongs in the acquisition price.

Integrating Technology Assessment into the Deal Process

Technology assessment shouldn't run as an isolated workstream. It belongs inside the broader operational diligence, feeding a single view of whether the company can execute its plan.

Pre-LOI screen. A focused read of engineering productivity, deployment patterns, and debt signals can flag targets where technology will drag on value creation. Done from metadata, this takes days rather than weeks, and it can change the bid, or end the pursuit, before diligence costs mount.

Diligence-phase deep dive. During formal diligence, pair the metadata findings with targeted technical interviews. Let the data set the agenda. "Deployment frequency fell 40% over the last two quarters. What's driving that?" "Build times keep lengthening. Is that a recognized issue?" Questions grounded in evidence get more honest, more productive answers than open-ended prompts about the roadmap.

Valuation impact. Translate findings into numbers the deal team can use. If 40% of engineering capacity goes to technical debt, and the company employs 50 engineers at a fully loaded cost of $250K each, the debt costs roughly $5M a year: capital maintaining the status quo rather than building value. Projected across the hold period, that materially changes the return calculation.

Value creation planning. Technology improvement is one of the more predictable levers in a private-equity-backed company. Reducing debt, improving deployment practice, modernizing architecture, investing in developer productivity: each has a well-understood playbook and timeline. The pre-close assessment provides the diagnostic baseline for the 100-day technology plan.

Technology isn't a black box only CTOs can evaluate. The records an engineering team generates are as legible to a disciplined analyst as financial statements are to an accountant. Look past the architecture diagram, measure what the team actually does, and technology assessment becomes a quantitative exercise. For investors willing to do that work, it's a durable edge.

The Request List: What Each Artifact Actually Proves

Most technology diligence request lists are copied from a template and padded for safety. A better list is shorter and sharper. Every item earns its place by proving something specific, and the workstream knows in advance what that something is.

• The architecture diagram, dated. It proves what the team believes the system looks like. Ask when it was last updated. A diagram untouched for two years proves something else: documentation is not part of how this team works.
• Twelve months of deploy history, pulled from the pipeline rather than a summary slide. It proves release cadence, seasonality, and whether shipping clusters around heroic weekends.
• The incident log, with postmortems. It proves how the organization behaves under stress. Read the follow-up actions, then check whether any of them shipped.
• The dependency manifest, or a software bill of materials where one exists. It proves what the product is actually made of, which is rarely what the diagram implies.
• Twelve months of cloud invoices, broken out by service. They prove where the money goes and whether spend tracks usage.
• The engineering org chart, with tenure and location. It proves structure, and it hints at concentration long before interviews confirm it.
• Third-party assessments (penetration tests, certification reports) with dates and scope. They prove what an outsider verified, and how recently.

Two disciplines make the list work. First, request raw exports over prepared summaries wherever the choice exists. Summaries are testimony. Exports are evidence. A prepared summary shows what management wants seen. The export shows what happened.

Second, treat a missing artifact as a finding rather than a gap to work around politely. A company that cannot produce an incident log either has no incidents, which is implausible, or does not record them, which is informative. Either answer belongs in the report, because how a company keeps its own records is itself evidence of how it runs.

Open-Source Licensing: The Liability Inside the Codebase

By volume, most commercial codebases are mostly other people's code: frameworks, libraries, and utilities pulled in as dependencies. That is normal, and usually healthy. The diligence question is what terms that code arrived under, because open-source licenses are contracts, and some of them carry obligations that collide with a commercial product.

The licenses sort into three rough bands. Permissive licenses (MIT, Apache, BSD) ask little beyond attribution and sit comfortably in almost any product. Copyleft licenses (the GPL family) can require that derivative work be released under the same terms, and the strongest variants extend that obligation to software offered over a network, which is exactly what a hosted product is. Source-available licenses restrict commercial use in ways that vary term by term, and several widely used projects have changed their terms in recent years, stranding companies that built on the older ones.

Three practices keep the review honest:

• Scan, do not survey. Ask the CTO which licenses are in the product and you get a recollection. Run a scanner across the repositories and you get an inventory. The two frequently disagree, and the size of the gap is itself a finding about engineering governance.
• Check obligations against how the product ships. A strong copyleft dependency may be a non-issue in an internal tool and a serious problem in a distributed or hosted one. The license doesn't change. The exposure does.
• Look past licensing to maintenance. A dependency kept alive by a single volunteer, or abandoned for years, is a different liability: no legal exposure, but every future vulnerability in it becomes the target's engineering problem to patch or replace.

Findings here are usually curable. Most problem dependencies have permissive substitutes, and remediation is a scoped engineering task rather than an existential threat. What matters is knowing the scope before close. A licensing surprise found by an acquirer's counsel after signing gets resolved on much worse terms.

Infrastructure Economics: The Cloud Bill as Evidence

For a software company, infrastructure spend is cost of goods sold. It deserves the scrutiny that working capital gets in financial diligence, and it usually receives none.

Start with one ratio: infrastructure cost as a share of revenue, tracked across eight to twelve quarters. Healthy hosted-software businesses commonly run in the single digits to low teens. The absolute figure matters less than the slope. Spend that grows in line with revenue describes a business that scales. Spend that grows faster than revenue describes a margin problem compounding quietly, and it will surface in the projections precisely when the growth plan needs the margin most.

Then decompose to unit cost: cost per customer, per tenant, per transaction, whichever unit the business actually sells. A falling unit cost means the engineering organization is earning efficiency as it scales. A flat or rising one means every new customer buys the company a slightly worse gross margin.

Specific items worth pulling from the invoices:

• Commitment structure. Reserved capacity and committed-use agreements trade flexibility for discounts. Note the terms and the expiry dates. A discount cliff six months after close is a real cost the projections should already carry.
• Spend concentration. One service or one workload dominating the bill is both a re-architecture candidate and a negotiating exposure with the provider.
• Tagging hygiene. If spend cannot be attributed to products or teams, nobody is managing it. Untagged spend is unmanaged spend, and it tends to grow.
• Idle capacity. Sustained low utilization on large instances often reflects fear: systems nobody dares resize because nobody is certain what would break.

The invoices also test the narrative. A target claiming efficient architecture while its unit costs climb is telling two incompatible stories. The billing data is the version under oath, and reconciling the two versions is exactly the kind of question a diligence interview exists to ask.

Build, Buy, or Rewrite: Pricing Platform Risk

Somewhere in most technology diligence, the rewrite question surfaces. Sometimes management raises it: the platform needs modernizing, the deck says so. Sometimes the signals raise it instead: velocity falling, senior candidates withdrawing after technical interviews, maintenance consuming half of capacity. Either way, the question needs a priced answer, because a full platform rewrite is among the riskiest projects a software company can attempt.

The base rates are unkind. Rewrites routinely run to twice their estimated timeline, freeze feature delivery while the old and new systems run in parallel, and lean hardest on the exact engineers the company most needs to retain. A hold period runs four to six years. A rewrite that consumes two of them, plus a year of stabilization, leaves little room for the growth the deal was priced on.

The diligence work splits by situation:

• A rewrite already underway. Ask for the cutover plan, the share of production traffic on the new system today, and the date the last feature shipped on the old one. A rewrite with no traffic migrated after a year of effort is a science project wearing a roadmap's clothes.
• A rewrite proposed but not started. Treat the proposal as a symptom and size the underlying technical debt independently. Incremental modernization, replacing the system piece by piece behind stable interfaces, is slower on paper and far more survivable in practice. A team that never seriously evaluated it is showing you its appetite for risk.
• No rewrite discussed. Test whether one is latent. When the debt signals sit past their thresholds and hiring against the current stack keeps failing, the rewrite is coming whether or not the deck mentions it.

The same discipline covers build-versus-buy. Every in-house system that duplicates a mature commercial product (billing is the classic case) is capacity the plan cannot spend elsewhere, and its replacement or upkeep cost belongs in the underwriting.