Technical Due Diligence for PE and Mid-Market Buyers

Technical Due Diligence for PE and Mid-Market Buyers

When I sit in a data room, technical due diligence is the engineering test. I compare the designed system to what actually runs. I price a real change in the code. I test whether the data model, the integration contracts, and the telemetry can survive the first operating plan. I am not counting languages.

Buyers who search this phrase get a stack inventory or a generic architecture brochure. I write this page for the operating partner who has to own the system if the seller's design slide is a wish.

Pineapples prices the hired version as Technology Diligence, 10 business days from data-room access.

What is technical due diligence when a buyer types it?

Technical due diligence is the phrase PE, mid-market, and family-office buyers type when they want an engineering read, not a tool list. They are asking whether the system can carry the thesis after the people who drew the diagram hang up.

I treat that as a live-file question. Does the designed failure domain match how production actually fails. What does one real change cost in modules and coordination. Can the data model express the plan the memo assumes. Do the integration contracts and the telemetry tell the truth without the seller in the room.

A stack list answers a different question. It lists services, a queue, Postgres, and an observability vendor. All of that can be accurate. None of it tells you the "services" share one database, a pricing change touches half the repo, customer identity has two sources of truth, or the revenue path has no trace.

This page is that read. Software due diligence is the delivery test, whether you can change and ship after close. IT due diligence is the lockout, MFA and domains and bank admin. Vendor due diligence is the counterparty, tenant and export and who can cancel the bill. The wider buyer and seller review, from architecture through intellectual property, is later on this page. Do not treat the delivery, lockout, and vendor tests as this engineering read.

How is the engineering test different from the delivery, lockout, and vendor tests?

Search "technical due diligence" and you land on language lists, maturity scores, and the same checklist used for "technology due diligence." Fine work for a combined diligence team. It is not the engineering question.

A PE operating partner heading to IC still needs a shorter, uglier list:

• Whether the designed system is the one that fails in production
• What a thesis-critical change actually costs in the code
• Whether the data model can hold the plan, or forces a rewrite
• Whether integrations are contracts, or shared tables and silent side effects
• Whether anyone can see a revenue incident without calling the seller

If your packet cannot answer those, you have a stack brochure. You do not have technical due diligence for a live file.

Software due diligence still matters. A pipeline that only runs on one laptop is a Monday problem. It is not the same problem as a data model that cannot express a second product line. One is delivery. The other is engineering. Confusing them is how a clean ship path still blows the first-year plan.

An AI readiness assessment will fail the same way if you score tools and skip the model and the telemetry. A stack quiz with no source of truth is still a fail.

What do I prove about systems design versus production?

I do not start by scoring the architecture style. Monolith versus services is a caption. I start by walking a real failure and a real change through the system that actually runs.

Failure domain. The slide shows isolated services. Production shares a database, a lock, or a worker that every path waits on. If one box going down takes the rest with it, isolation is a narrative. I write the shared resource, not the service count.

Control flow. The deck says event-driven. The money path is request and reply plus a cron that nobody owns. Hidden jobs, "temporary" workers, and feature flags that became load-bearing architecture all sit here. I follow the request that bills a customer. I do not follow the pretty graph.

Consistency. The design promises eventual consistency. Production dual-writes two stores and reconciles in a spreadsheet. Or it does not reconcile. That is not a style debate. That is a reporting and refund problem waiting for the first board pack.

Capacity story. The memo assumes the current shape can absorb the thesis. I look for the single-writer lock, the table that cannot be partitioned, the job that already runs long on a quiet day. I am not forecasting traffic. I am asking whether the designed headroom exists in the runtime.

I write those as objects I can show. A connection string two services share. A job that is the real orchestrator. A lock that serializes the money path. I do not write "architecture is complex."

The diagram is the finding. Design that is not production. Code that is change cost. A data model that cannot hold the thesis. Integrations and telemetry that are blind. That chain is a slide you cannot operate. The stack list is the side path.

How does code quality show up as change cost?

Code quality is not a coverage percentage. Coverage can be high and still assert a mock. I treat quality as the cost of a change the thesis requires.

I pick one change the board will ask about. A price. A tax rule. An entitlement. A second SKU. Then I walk it.

Blast radius. How many modules, tables, and jobs have to move together. If a one-line commercial change fans out across a god module and three silent side effects, I write the fan-out. That is a reserve, a holdback, or a no on a timeline that assumes weekly product motion.

Second person. How long before someone who did not write the module can change it without the author. If the answer is "we would wait for the founder," the code is a person. Software due diligence will catch the release path. This test catches the module that cannot be touched even when the pipeline is green.

Hidden coupling. Circular imports. Implicit globals. Shared mutable tables used as an API. Tests that lock the mock in place. These are not style notes. They are why the first post-close roadmap slip is already priced into the code.

I do not invent a dollar figure for "tech debt." I attach the change I walked and the coordination it requires. Finance can put a number on that. A letter grade cannot.

What does a 10-day code audit deliver?

A code audit service is an operator reading the repo and writing what a buyer can change, and what that change costs. The buyer gets a scoped read of the system that actually runs, the hotspots that make a thesis-critical change expensive, and a written findings memo with a prioritized fix list.

Pineapples runs it as the 10-day Technology Diligence seat. Same operator from data-room access to the readout.

• Scope. The engineering the thesis depends on: designed system versus production, one real change, the data model, integration contracts, and telemetry.
• Architecture and dependency review. I walk a failure and a change through what actually runs. Shared databases, hidden jobs, and a dependency that couples two systems through a table or a webhook get named.
• Security and license exposure. A money path with no trace and no owner on-call. A restrictive license (GPL or AGPL) in a proprietary path. A dependency the buyer inherits even if the logos novate. The lockout list (MFA, domains, bank admin) is a different test.
• Test coverage and deploy pipeline. Coverage can be high and still assert a mock, so a percentage is not the finding. I check whether tests lock the behavior the change needs, and whether a buyer can replay the deploy without the seller.
• Change cost hotspots. Blast radius, a second person who can touch the module, and hidden coupling. If a one-line commercial change fans out across a god module, I write the fan-out. I do not invent a dollar figure for "tech debt."
• Findings memo. A written memo with a prioritized fix list, not a letter grade. Each item is a fact, the evidence, a model effect (price, holdback, reserve, or timing), and a close condition or first-100-day action.

Where do data model, integration, and observability findings sit?

These three decide whether the operating plan is software or a rewrite.

Data model. Customer, order, and entitlement need a stable identity. If those live in two tables with no join key, or in a JSON blob that means three things, the thesis that needs a second product line, usage billing, or a clean cohort is already a migration. Soft-delete graveyards and dual sources of truth show up in the first reporting week. I ask for the query that produces revenue, then I ask for the query that produces the customer. If they disagree, the model is the finding.

Integrations. This is not vendor due diligence. I am not asking who owns the tenant. I am asking whether system A and system B have a contract, or a shared table and a webhook that fires twice. Batch files that are the real API. Implicit schemas over HTTP. No idempotency on the money path. A change in one system silently corrupts the other. That is engineering coupling you will inherit even if every logo novates cleanly.

Observability. Can a buyer engineer diagnose a revenue incident without the seller. Traces on the money path. Logs that explain, not logs that exist. An alert that pages a person who will still be here. If the only "monitoring" is a dashboard the founder watches, you cannot operate what you cannot see. IT due diligence will still catch the MFA lockout. It will not catch the empty trace on checkout.

I write those as evidence. A schema dump. A foreign write. An empty APM on the path that takes money. I do not write "needs better documentation."

What belongs on a PE technical finding list?

IC does not need another appendix of languages. IC needs engineering facts that change price, holdback, reserve, or timing.

I write each finding in four parts: the fact, the evidence, the model effect, and the close condition or first-100-day action.

• Designed services share one database. Evidence is the shared connection and the tables both write. Effect is isolation is a slide, so a service split is a project. Close condition is name the rewrite or accept the monolith in the plan.
• A thesis-critical change fans out across a god module and silent jobs. Evidence is the call graph on that change. Effect is the first-year roadmap assumes motion the code cannot deliver. Holdback or reserve until a second person can ship that change.
• Customer or order identity is split with no join key. Evidence is the two queries that disagree. Effect is reporting, add-ons, and any usage thesis start as a data rebuild. Price the migration before you price the synergy.
• The money path has no trace and no owner on-call. Evidence is the empty APM and the alert that pages a seller. Effect is you cannot prove or debug day-one revenue issues. Close condition is telemetry on that path and a named buyer-side owner.
• Integration is a shared table or a fire-and-forget webhook. Evidence is the foreign write or the missing idempotency key. Effect is you cannot migrate or pause one side. Sequence the contract, or sequence the delay.

If I cannot attach a screenshot, a query, a trace, or a call graph, I am not done. "Architecture is dated" is not a finding. "The designed services share one database, so isolation is a slide" is a finding.

A stack list can sit in the appendix. The memo is the finding list. That is the difference between technical commentary and something finance can use.

When the file is live and the model needs numbers, that is technology due diligence consulting. This page is the search phrase that seat sits on when the risk is the engineering, not the pipeline, the tenant, or the MFA code. The findings still have to land in a file someone runs on Monday. That is private equity software for lean teams, the system that writes diligence into the model and monitoring into a weekly file.

When do I hire the 10-day seat?

I hire the seat when the next decision is a price, a holdback, or a no, and the engineering can change that decision.

Pineapples prices Technology Diligence, 10 business days from data-room access. Same operator from access to the readout. Findings written so they can sit next to legal and finance.

That is the deal-room buy. It is not a second stack PDF. It is not a request to "send the repo and we will score it."

After close, if the company still needs a technology lead who owns that system week to week, that is Fractional CTO, pause or cancel any month. A later proof workflow is not this page. Talk it through. Neither replaces the engineering test on a live file.

I do not invent fees. The PE menu lives on the engagements page. If you want a short read on a live file before you buy the seat, start in chat.

What technical findings do I take into IC?

I take the engineering facts that break the plan, and I stop.

The design that is not production. The change that costs a project. The data model that cannot hold the thesis. The integration that is not a contract. The money path you cannot see.

If those are clean, the stack list can wait. If they are not clean, the stack list does not matter yet.

I run this as owner-led work. Same person in the data room and in the readout. If you have a live file, bring it to chat or see the PE engagements. I will sit in the system.

What else does a mid-market technology review cover?

The engineering test above is the live-file question. Buyers and sellers still need the wider review, because a stack inventory is not the same document.

Architecture and infrastructure. How the application is built, where it runs, whether infrastructure is defined as code, and where a single failure takes the business down. The question is whether the shape can carry the plan, not a cloud logo.

Code quality. Dependency age, how long a change takes to reach production, and how much engineering time goes to maintenance. A coverage percentage is not the finding. The finding is whether a thesis-critical change can ship without heroics.

Security and compliance. A recent third-party review, encryption, who can reach production data, and whether a breach was disclosed. Security findings rarely kill a deal by themselves. An undisclosed breach does, because the issue is the dishonesty.

Team and knowledge. Headcount matters less than key-person risk. If the people who understand billing leave after close, the buyer inherits a system nobody can change. Documentation and a second owner are the evidence.

Intellectual property. The company either owns the code or it does not. Restrictive open-source licenses, contractor work without an assignment, and unresolved patent questions can delay or stop a close.

Deal killers versus price reducers. An undisclosed breach, total dependence on one platform with no backup, and license contamination that can force the product open are the findings that stop deals. Key-person risk, a stack that is hard to hire for, no automated testing, hand-configured servers, and customer-specific forks more often change the price or the plan.

Seller preparation. Start a year or more before a process. Fix what an independent read finds. Write down what only lives in someone's head. Cross-train. Near close, run a security review and put the architecture, the stack, the org chart, the deploy path, incident history, and the dependency list in a data room. Practice the hard answers. A known weakness with a plan is a better readout than a discovered weakness with none.

Buyer habits. Staff the review with people who have built similar systems, not only a checklist. Weight those areas by the thesis. Talk to the engineers who ship on a Tuesday, not only the leader who presents the deck. Ask what they would fix with a few months and no feature pressure. Every finding should name what it does to the plan. "Technical debt" with no effect on price, holdback, reserve, or timing is not a finding.

The ten sections that move a PE model (leadership, knowledge concentration, day-one reporting, TSA dependency, ERP carve-out, cybersecurity, vendor concentration, change capacity, integration readiness, and synergy model risk) stay on the M&A technology checklist.

What should I read next?

• Software Due Diligence for PE and Mid-Market Buyers
• IT Due Diligence for PE and Mid-Market Buyers
• Vendor Due Diligence for PE and Mid-Market Buyers
• Technology Due Diligence Consulting for PE and Mid-Market Buyers
• Private Equity Software for Lean Teams