Across the 26 apps I audited, 22 had at least one confirmed-critical finding. A technical due diligence consultant is hired to find problems like those and write them up for whoever pays, usually a buyer or an investor. So start with your seat: the company being read fixes what it knows first; the side reading buys the report.
What you are actually buying from a technical due diligence consultant, and from the three sellers next to them
A technical due diligence consultant reads a company’s code, infrastructure and team for whoever hired them, usually a buyer or investor, and hands back a report. A fractional CTO works for you monthly. A code audit firm reports on the code alone. A fix-first engagement changes the code and returns evidence. The buyer’s reviewer works for the buyer, not you.
The 22 in the opener is out of all 26 apps I audited in June and July 2026: 21 third-party apps, some public and some held out, plus five of my own. That is a selected set of audited apps, not a random sample, and it is no rate for AI-built apps in general. This page is the buying guide to technical due diligence services inside production hardening: who to hire when somebody is about to read your code, and in what order.
The table is my reading of how each seller type works, not a quote from any one firm.
| Seller | Who they work for | What you get back | How it is usually sold | The wrong buy when |
|---|---|---|---|---|
| Due diligence consultancy or firm | Whoever hires it, usually the buyer, investor or board | A written report of findings | Per engagement | You are the company being read and your known list is still open |
| Fractional CTO | You | Technical decisions and leadership, month by month | By the hour, the day or the month | You need a finished list of fixes by a date |
| Code audit firm | Whoever pays | A report on the code | Per audit | The buyer wants infrastructure, team and process read too |
| Fix-first engagement | The company being read | Changes to the code, plus the evidence for each | A fixed scope | A buyer requires an independent opinion |
The label on the seller tells you little: a specialist technical due diligence company, a large consulting firm and a single consultant can all be selling the first row, and the size shows up in the team and the invoice, not the method. What technical due diligence consulting services hand back is that first row’s written report; the fixing stays with you. Some tech due diligence firms also sell a preparation read to the company being read, which the due diligence article below covers in its FAQ on getting prepared. If you are the founder, a firm doing technology due diligence consulting for your buyer is not working for your company, however friendly the first call, and its services end with the buyer’s report.
The second row has its own pages. The units a fractional CTO is sold in, and the prices sellers publish for each, are in what CTO as a service costs; what the arrangement is under its other names is in an outsourced CTO; and the choice between one and a development shop is fractional CTO vs agency. For the third row, how to choose a code audit service covers comparing sellers and judging a sample report.
What technical due diligence is, who turns up for it, and what a reviewer finds in AI-built code are in the due diligence article, so they are not re-told here. One boundary: this page is about software. Technical due diligence consultants in the engineering and property sense, who survey plants, data centers and buildings, sell a different service.
What it costs
Technical due diligence cost is rarely published: of the nine ranking guides and service pages checked for this page, only one prints a price. Ask each firm for the unit of its quote, such as a fixed fee, a day rate or a timeframe, before you compare two of them.
The one is MEV’s guide, and its figures are for MEV’s own work, not a market range. The other eight pages checked were BD Emerson’s list of firms, the guides from TechMiners, DFIN, Snyk and M&A Science, and the service pages of Bain & Company, Crosslake and BCG. KMS Technology’s page refused a generic request on September 27, 2026, so nothing of its is printed here.
| Seller type | What the pages checked publish about price or time | Source and date |
|---|---|---|
| Due diligence firm: Bain & Company | No fee, rate or engagement length; one client story mentions a PE firm’s “two-week window” to get answers | Bain’s tech due diligence page, September 27, 2026 |
| Due diligence firm: Crosslake | Not published | Crosslake’s tech due diligence page, September 27, 2026 |
| Due diligence firm: BCG | Not published | BCG’s due diligence page, September 27, 2026 |
| Due diligence firm: MEV | ”typically range from $5,000 to $30,000, depending on the size and complexity of the system”; the core audit “runs two to four weeks for most engagements at MEV, depending on system size, complexity, and how quickly access is granted” | MEV’s technical due diligence guide, September 27, 2026 |
| Due diligence firm: KMS Technology | Not checked: the page refused a generic request | September 27, 2026 |
| Fractional CTO | Priced by the unit it is sold in; the published figures, seller by seller, are in the fractional CTO cost article linked above | That article’s own dated sources |
| Code audit firm | Depends on how much gets reviewed, the access given and the evidence asked for; the code audit article covers it | The code audit article linked above |
| Fix-first engagement | A fixed scope, with the price on the seller’s own page | The seller’s page |
What moves a consultancy quote, as I read it: the size of the codebase, how many systems sit behind it, the deadline, and whether you want a red flag report or a full one. In my reading, a small app with one repository and one database sits at the low end of each.
When to pick each
Buy the independent read when a buyer, an investor or a board requires one, or when you are the buyer. If you are the founder and you already know what is broken, fix the known list and build the evidence pack first, then let the reviewer read a prepared codebase.
A due diligence consultancy
If you are the buyer, this is your hire. It also fits when you are the company being read and a buyer, an investor or a board requires an independent reviewer with a named method: their requirement decides it, not your preference.
It does not fit when you are the company being read and the known list is still open. I think you would pay for a report of things you already know, and the buyer would still want their own reviewer afterwards.
What a due diligence consultant does, in practice, is read the code, interview the team, run tools against the repository and the running system, and write the report. That is my reading of the engagement, not a quote. The scope a buyer’s reviewer covers is the target company’s software, hardware, infrastructure and engineering team.
A fractional CTO
If what you are missing is a technical leader who can face an investor’s questions over months, a fractional CTO fits. They sit on your side of the table, which no reviewer does.
It does not fit when the deadline is a data room in a few weeks and nothing is fixed yet. A monthly adviser can tell you what to fix; somebody still has to do it before the reviewer arrives. The prices and the agency comparison are in the cost article and the comparison page linked in the first section. Whether a fractional CTO is the right hire at all, direction versus one piece of work, is its own question, answered in when you need a fractional CTO.
A code audit firm
If one dimension is in question, a code audit fits: security before a customer contract, or quality before you decide whether to rewrite.
It does not fit as the whole diligence. A buyer’s reviewer also reads the hardware, the infrastructure and the engineering team, the rest of the scope above, and a code audit stops at the code. The code audit article linked in the first section covers how to compare these sellers.
Fix the known list first, then the independent read
If you are the company being read and my audit numbers describe your app, fix first. At least 23 of the 26 audited apps had zero working automated tests. At least 17 of the 21 third-party apps had no deploy gate, and so did all 5 of my own apps: every push ships straight to production with nothing checking it first.
Both counts come from the same audits: 26 apps in June and July 2026, 21 of them third-party apps I picked, public and held out, and 5 of them my own. Nothing was drawn at random, so read the numbers as where to look first, not as odds for your app. What to fix, in order, is the section on fixing before they look in the due diligence article linked in the first section.
The order I would follow: fix the known list, then build the evidence pack (the technical documentation for investors), then let the buyer’s technical due diligence review read a prepared codebase. The flags that reviewer looks for are in what investors look for in code. If the read is for a sale rather than a round, the seller’s side is its own subject: due diligence of code when selling a business.
On the Production Hardening Sprint, deliverable 13.6, the technical due diligence pack, bundles the readiness report, architecture diagram, data model, security checklist, and capacity statement into one PDF. Deliverable 13.6 is verified this way: check the pack for completeness, consistent version references, and readable linked evidence.
Fix-first does not fit when the buyer has already appointed a reviewer and the clock has started. Then the read comes first and the fixes follow its findings, because changing the code under a reviewer’s feet makes their report describe an app that no longer exists.
What to ask a technical due diligence report to contain
A technical due diligence report is worth paying for when it names its method, shows that someone read the code, and ranks findings by severity with a way to fix each. My working rule asks for seven sections. A red flag report is the condensed form: it mainly covers the threats that may stop the deal, not the full assessment.
The seven sections below are my request list, not a standard and not a quote from any firm.
- 01 Scope and method: what was read, what was left out, and how each part was checked
- 02 Architecture and stack: the parts of the system and what each one runs on
- 03 Code quality and tests: what the code is like to change, and what checks it
- 04 Security and data: who can reach what, and where personal data sits
- 05 Infrastructure and operations: hosting, deploys, backups and monitoring
- 06 Team, process and ownership of the code: who maintains it and who owns it
- 07 Findings ranked by severity, each with a way to fix it
RSM’s Poland office, writing about transaction advisory work, says a red flag report “mainly involves identifying threats that may prevent a transaction from being successfully completed”, and calls it “more condensed than other due diligence reports”. The technical version works the same way, as I see it: a short list of what could stop or reprice the deal, written by someone who read more than the list shows.
The technical due diligence report format I would accept puts the evidence beside each finding: the tool output, a screenshot, the commit that was read, so anyone can check it. There is no sample to show here; a technical due diligence report example from a firm, redacted, is worth asking for before you pay.
“TDD” in a deal document means technical due diligence, the abbreviation Snyk uses in the title of its guide, and a tech due diligence report is the same document under the short name. In engineering the same letters mean test-driven development.
The item-by-item checklist a reviewer sends you, and what a due diligence report is and who writes it, are in the software due diligence checklist. Due diligence outside software, as a general idea, is a wider subject: the definition of due diligence.
Questions to ask before you pay
Each question has one line on what a good answer sounds like, in my reading. Ask all eight before any money moves.
- 01 Who is the client, me or the buyer? A good answer names one party and says who sees the report first.
- 02 What does the report contain, section by section? A good answer maps onto the seven sections above, or says which it leaves out and why.
- 03 Who reads the code, and have they read a codebase that came out of an AI builder? A good answer names the person and the stacks they have read before.
- 04 Which tools run, and do I get their output? A good answer lists the tools and hands over the raw output with the report.
- 05 What is the price shape, and what changes it? A good answer gives the unit, fixed fee, day rate or timeframe, and the things that move it.
- 06 How long from access to report? A good answer counts from the day access is granted, not the day the contract is signed.
- 07 Is a re-read included after fixes? A good answer says yes, or prices it separately, and says what the re-read covers.
- 08 Can I see a redacted sample report? A good answer is a real report with the client removed.
Question 3 is the one I would not skip. In one app I audited, a freelancer dashboard’s README sold features the code did not contain. A report written from that README would have described features that did not exist. The lesson I take from it: ask who reads the code, and expect the report to name the commit they read, because a reviewer working from the documentation describes the app the documentation sells.
How to judge that sample once you have it, for question 8, is covered in the code audit article linked in the first section.
Where the sprint fits
For the company being read, the Production Hardening Sprint is the fix-first option. At handover you receive the updated codebase, tests and deployment configuration, a readiness report and the technical due diligence pack described under fixing the known list, instructions for releases, backups, recovery and incident response, guidance and automated checks for future AI-assisted changes, and a recorded handover and codebase tour. It covers one codebase. Formal third-party certifications and independent audit opinions are separate from the sprint deliverables, so the pack is evidence for the buyer’s reviewer, not the review. Every deliverable is listed in the published scope.
The questions a reviewer asks about how you store and protect customer data fall under data security, a separate subject.
Common questions about hiring for technical due diligence
What does a due diligence consultant do?
A due diligence consultant reviews a company before someone commits money to it and writes up the risks for whoever hired them, usually a buyer or an investor. On the technical side that means reading the systems and the people who run them, through the code, interviews and tool output, and ending with a written report.
What is a red flag DD report?
A red flag due diligence report is the short version of the review: it mainly lists the threats that could stop the deal from completing, rather than the full assessment, and rates the risk of each. RSM says those ratings are most often low, medium or high, and can also be drawn as green, yellow and red flags.
How much does a due diligence report typically cost?
For technical due diligence, the price is usually not published. Of the nine ranking pages checked on September 27, 2026, only MEV’s guide printed one, for its own work: a software target typically costs $5,000 to $30,000, quoted upfront, with the range set by system size, complexity, and how many products or regions the review covers. Ask any other firm for the unit of its quote and what moves it before you compare two of them.
What does TDD stand for in a document?
In a deal or investment document, TDD stands for technical due diligence, the review of a company’s software, infrastructure and team before money changes hands. In an engineering document it usually means test-driven development, where a test is written before the code it checks.
Owning an app means being able to run it, change it and recover it without guessing. The sprint below leaves you with the runbooks and documentation to do that.
Built it with AI. Now it has to hold up for real customers.
The Production Hardening Sprint takes the app you already have and builds the production foundation underneath it. Authentication and access rules, payments that stay consistent, error handling, monitoring, backups, automated tests and a documented handover. Our engineers work inside your existing codebase for ten working days. All 123 deliverables are included, and you get the evidence for each one.
See the Production Hardening Sprint → 
$2,500 fixed price · 10 working days · One codebase