Software Due Diligence for PE and Mid-Market Buyers

When I sit in a data room, software due diligence is the work of proving you can change and ship the product after you buy it. I look at whether the architecture matches production, whether the pipeline runs without one laptop, and whether anyone besides the seller can cut a release. I am not counting languages.

Buyers who search this phrase get a stack inventory or a generic code-review brochure. I write this page for the operating partner who has to ship a change if the seller does not take the Monday call.

Pineapples prices the hired version as Technology Diligence at $25K or $60K, 10 business days from data-room access.

What is software due diligence when a buyer types it?

Software due diligence is the phrase PE, mid-market, and family-office buyers type when they are about to pay for a product they did not build. They are not asking for a history of programming languages. They are asking whether the software still ships if the people in the data-room Zoom hang up.

I treat that as a live-file question. Can a buyer engineer clone the repo and get a green build. Can anyone deploy without the seller's laptop. Can a one-line fix reach production without a private script nobody documented.

A stack list answers a different question. It lists React, Postgres, a service mesh, and an AI copilot. All of that can be accurate. None of it tells you the architecture slide is a wish, the only working pipeline lives on one MacBook, or the last release required a founder who is leaving.

This page is that read. 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 mid-market technology due diligence guide is the longer stack explainer. Do not treat those as the same document.

Why does a stack inventory miss the IC question?

Search "software due diligence" and you land on language lists and maturity scores. Count the repos. Score the test coverage. Rank the cloud. Fine work for a combined diligence team. It is not the Monday ship.

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

• Whether the architecture diagram matches what is actually deployed
• Whether CI runs on a machine the buyer will still have
• Who can merge, tag, and press deploy after the announcement
• What happens if the one person who understands the release path does not take the first buyer call

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

I do not need the inventory to be wrong to say that. I need the ranking page to be honest about what it is. It is a stack catalog. It is not a walkthrough of the pipeline that only goes green on one laptop.

An AI readiness assessment will fail the same way if you score tools and skip the owner who can ship. A stack quiz with nobody on the release path is still a fail.

What do I open first in the repo?

I do not start with the language spreadsheet the banker uploaded. I start with the objects that decide whether a buyer engineer can change the product.

Architecture versus production. Open the diagram in the data room. Then open what is actually running. If I see a tidy service map and a production graph that does not match it, I treat the slide as seller narrative until someone walks the deploy. Hidden jobs, personal forks that serve traffic, and "temporary" workers that have been temporary for years all sit here.

Pipeline. Ask for a clean clone and a CI run on a machine that is not the seller's. A green build on one laptop is not a pass. A pass is a pipeline the buyer can replay without a private env file, a local Docker daemon nobody wrote down, or a script that only exists in one home directory.

Knowledge. Who can change the billing module, the sync job, the thing that prices the product. If the answer is one name, write the module as a single point of failure. Documentation that says "see Alex" is not documentation. It is a holdback candidate.

Release. Who pressed the last production deploy. What they clicked. Whether that path still works if that person is on a plane. I am not asking for a DevOps essay. I am asking whether the buyer can ship a one-line fix on Monday without texting the seller.

I write those as objects I can screenshot. I do not write them as a maturity score.

The diagram is the finding. Architecture slide that is not production. Pipeline that only runs on one laptop. Knowledge that sits in one head. Release that still needs the seller. That chain is a product you cannot change. The stack list is the side path.

Where does day-one delivery risk actually live?

Day one is the first morning the buyer has to ship without the seller in the room.

Delivery risk lives in boring places:

• The architecture slide shows six services. Production is one process and three cron jobs on a box nobody listed
• CI is green only on the founder's laptop because the secrets file never left that machine
• Merge rights sit on a personal GitHub account, and the org transfer is "after close"
• The last production release was a manual copy from staging, and the person who knows the order is leaving
• The demo path is clean. The overnight job that actually bills customers lives in a repo the banker did not upload

None of those show up as a row on a language inventory. All of them show up if you sit down at a clean machine and try to do one real ship.

I also look for the change the board will ask about in week one. If a pricing tweak or a bugfix can only be released by the seller, you do not have software you can inherit. You have a person. That person may be leaving. I write that in the memo. I do not turn it into a branded score.

The cheaper time to find that is before the announcement. After close it becomes a fight with a pipeline that has no reason to help you. Same objects. Worse timing. IT due diligence will still catch the MFA lockout. It will not catch the build that only the seller can run.

What belongs in the IC memo?

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

I write findings as actions:

• Reproduce a green CI run on a buyer-controlled machine before close, or hold funds until that path is live
• Reconcile the architecture slide to production, and name every job that carries revenue that the slide omitted
• Move merge and deploy keys onto a company-owned org with two buyer-controlled admins
• Name two people who can cut a production release on a path that does not require the seller
• Map the modules that only one person can change, and price the time to make a second person real

If I cannot attach a screenshot, a CI log, or a deploy record, I am not done. "Documentation is light" is not a finding. "The only working pipeline leaves with the seller" is a finding.

A stack list can sit in the appendix. The memo is the delivery list and the cost or delay to clear it. That is the difference between software 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 codebase, not the tenant and not the MFA code.

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 software can change that decision.

Pineapples prices Technology Diligence at $25K or $60K, 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 language PDF. It is not a request to "send the repo and we will review it."

After close, if the company still needs a technology lead who owns that delivery week to week, that is Fractional CTO at $15K or $35K a month, pause or cancel any month. Build work on systems you already control is AI-Native Build from $4,500 per 2-week sprint. One shipped proof workflow, later, is the Starter Workflow Pilot at $4,900, 7 business days. None of those replace the pipeline check on a live file.

I do not invent fees. The PE menu lives on the engagements page.

What do I take into IC?

I take the objects that stop you from shipping, and I stop.

The architecture that is not production. The pipeline that only runs on one laptop. The module that lives in one head. The release that still needs the seller.

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, scope the 10-day seat. Bring the target. I will sit in the repo.

Related reading

• Vendor Due Diligence for PE and Mid-Market Buyers
• IT Due Diligence for PE and Mid-Market Buyers
• Technology Due Diligence for Mid-Market Acquisitions
• Technology Due Diligence Consulting for PE and Mid-Market Buyers
• Fractional CTO for Mid-Market and PE