Digital Engineering/AI Product Assurance/Software Technical Due Diligence
Diligence on an AI-built asset, before the money moves
By the time technical diligence starts, the price is usually on the table. What is not settled is whether the asset underneath it can be operated, extended and owned by somebody other than the person who built it.
Why the standard checklist misses an AI-built asset
Most technical diligence checklists assume a proportional relationship between the size of a codebase and the effort that produced it, and many inferences hang off that assumption. On an AI-built asset it stops holding. Three people can present a product with the surface area of a company five times their size, and the question becomes not how much was built but how much is genuinely held.
How much of this was generated, and does anyone hold it in their head?
No detector reliably labels generated code, and any supplier claiming one is overselling. Repositories do carry signals: commit size and cadence, uniform boilerplate across unrelated modules, three solutions to one problem in three styles, tool configuration committed alongside the source. We treat the proportion as a question for management, corroborated against those signals rather than asserted from them.
Does the velocity survive one departure?
A team shipping weekly may be doing so because its practice is strong, or because one person has an unusually good working relationship with a set of tools and a system only they can navigate. Those look identical on a delivery chart and behave differently after an earn-out.
Where did the code come from, and what arrived with it?
Generated code pulls dependencies in quietly, and the obligations attached to them travel with the asset into the buyer's estate.
Is the small efficient team actually a small efficient team?
Or one capable person, two operating tools competently without being able to change what those tools produced, and a review process in name only.
Does the build speed reflect engineering capability or tooling?
The distinction rarely matters before a deal and always after one, because the roadmap the price rests on has to be delivered by whoever remains.
Who commissions this
Investors, acquirers and corporate development teams.
You have a target, a timetable and an investment committee that will not accept “the engineers had a look and seemed happy”. You need a technical view that stands up in a paper: specific findings, costed, with the difference between an inconvenience and a structural problem made explicit. You need it fast, because exclusivity has an end date and technical work is rarely first in the queue.
Lenders and advisers to a transaction.
Where the underlying security is a software product, its maintainability is part of the credit picture.
Founders and their boards, ahead of a raise or a sale.
This is the second track on this page. Diligence is going to happen, someone else will run it, and their report will protect a party that is not you. Reverse diligence puts the same examination in front of you first, while a finding is still a task rather than a negotiating position held by the other side.
Both tracks use the same assessment. What differs is who instructs us, who receives the findings, and what the report supports.
What we assess
Every engagement is assessed against The Noseberry Product Assurance Framework. The same six dimensions we apply to an audit, a cleanup or a readiness review, so a target's report is comparable with any other assessment in the cluster. The evidence behind each dimension is published in full. Three further dimensions apply only to diligence engagements.
Read the assessment methodologyCode Health
What a new team must spend before it can safely change this system, and how much of the codebase is coherent enough to extend rather than work around.
Whether controls are applied across the product or only where somebody thought to ask. Assessed against OWASP ASVS and the OWASP Top 10, with secure-SDLC practice referenced to NIST SSDF.
Product Architecture
Whether the structure supports the roadmap the valuation rests on, or whether its first two items mean rebuilding a foundation.
Scalability & Performance
The point at which the design stops holding, expressed against the growth case in the model rather than in the abstract.
Cloud & Delivery
How releases happen, how they are reversed, and how infrastructure cost behaves at three times usage.
Engineering Governance
How change is proposed, reviewed and released, where AI tooling sits in that process, and what survives the founder's notice period.
Code Provenance & IP
Diligence only
Dependency inventory, licence obligations traced through transitive dependencies, and the controls applied to AI-generated code.
Team Capability & Key-Person Concentration
Diligence only
Where knowledge actually sits, evidenced from repository history and tested in interviews.
Cost to Remediate and Integrate
Diligence only
What it takes, in engineering months and in money, to bring the asset to a state the acquiring party can operate, and for a trade buyer to bring it inside an existing estate.
The security dimension is assessed against OWASP ASVS and the OWASP Top 10, and secure development lifecycle practice is referenced to NIST SSDF. We identify gaps relevant to those standards and do not certify compliance against them. Each dimension carries a status of Critical, Needs Attention or Ready, and every finding underneath it is classified and costed.
Code provenance, licences and open source
Open-source exposure is rarely a technical problem. It becomes a deal problem, and it surfaces late, because nobody looked until a lawyer asked.
We build the inventory.
Every dependency in the tree, direct and transitive, with its version, its source and the licence attached to that version. Version bumps change licences more often than teams expect, and the obligation attaches to what is shipped.
We identify copyleft exposure and describe how it arises.
Strong copyleft terms in a distributed component behave differently from the same terms in a hosted service, and network-copyleft licences remove that distinction. We set out which components carry those obligations and what replacing one costs.
We assess provenance controls rather than origin.
No method reliably establishes the origin of code produced by a model, and we will not pretend otherwise. What can be assessed is the control environment: which tools were approved and how configured, whether suggestion-filtering or attribution settings were on, what the review record shows, and whether contributor and contractor agreements assign the output.
We report this as deal risk, not legal opinion.
Findings go to counsel with locations, versions and obligations set out plainly. We do not advise on infringement, interpret a licence, or say a product is clear to distribute.
Key-person risk and what the repository can honestly tell you
A small team is an asset. A small team where one person is the only route to a working release is a liability priced as one.
What repository history supports.
Authorship concentration by module rather than across the whole codebase, which is where concentration hides. Review participation, whether changes were read by a second person or merged by their author. Commit shape, since large single-drop commits with no later iteration suggest code that arrived rather than code that was worked. Incident patterns, showing who got called.
What it does not support.
History records who committed, not who understood. It cannot separate an employee from a contractor whose agreement has ended, identify who directed the tooling, or say who is retainable after close.
How we test it.
Two structured technical interviews per key contributor, under the confidentiality terms of the engagement. We ask an engineer to walk us through a subsystem they did not recently touch, explain a decision that could have gone the other way, and describe what happens when a specific dependency fails. Capability shows up quickly, and so does its absence. We report concentration as a distribution with named gaps rather than a score, and we say where the evidence stops.
What actually moves a price
A report listing forty problems without weighting them hands the work back to the reader. Findings are costed and sorted into deal terms.
Remediation cost, in engineering months and in money.
Each material finding carries an effort estimate in engineering months at a stated seniority level, converted at a rate you nominate so the number sits in your model. Uncertain estimates are ranges, with the driver named.
Integration cost, where there is an acquirer.
Identity and single sign-on, data migration into existing platforms, consolidation onto the buyer's cloud accounts and monitoring, and the time to meet an internal security baseline. Routinely the largest number in the report, and absent from the model.
A clear line between a discount and a walk-away.
Most findings are money and time. A few are not, and confusing the two costs deals both ways.
Class
What it means
Typical deal response
A structural condition the price cannot absorb. The asset cannot transfer as described, or the product must be rebuilt to deliver the plan.
Withdraw, or reprice as an acquihire.
Real remediation at a defensible cost, borne by the buyer after close.
Adjust consideration by the costed amount.
Fixable before completion, and better fixed by whoever built it.
Condition to closing, or an escrow against it.
Manageable inside normal engineering budget after transfer.
Sequence into the 100-day plan.
Every finding also keeps its framework class of Critical, High, Medium or Optimisation, so the technical register reads alongside the deal view. We provide cost and risk inputs, not a valuation or a recommended price.
Reverse diligence: find it before they do
If you are raising or selling, technical diligence is not a risk you can avoid. It is an event with a date on it, and the only variable you control is whether you see the findings first.
What reverse diligence is.
The same examination a buy-side team would run, commissioned by you, delivered to you, nobody else copied. We read the codebase, trace the dependency and licence position, assess where knowledge is concentrated, and cost the remediation. Then we tell you which findings a competent counterparty will locate, roughly when, and what each looks like across a table.
Why founders do it.
A finding you present is a task with a plan attached. The same finding discovered by the other side is a bargaining chip, and it arrives when you have least room to move. The gap between those positions is frequently larger than the cost of closing it.
What we prioritise differently.
A buy-side report informs a decision. A reverse diligence report is written to be acted on, sequenced by what is both material and fixable inside your window. Six weeks before a data room opens, a licence obligation traced and replaced is worth more than a refactor nobody will finish. We are explicit about what cannot be fixed in time and how to present it honestly instead, because an issue disclosed early damages a process far less than the same issue discovered late.
What it is not.
It is not a certificate, not a document to publish, and it does not bind anyone else's diligence team, who will reach their own conclusions. Nor is it a script for concealment: if we think a finding must be disclosed, we say so, and we will not help you present a position we believe misleads a counterparty.
Run it before the data room, not during.
Founders who arrive after a deal has slowed usually wanted this conversation months earlier.
Working to a deal clock
Instruction and scope
day 0
A short call covering the transaction shape, the timetable, the thesis the technical view has to support, and the questions your committee will ask. We confirm we hold no conflict, execute the NDA, and agree access with the target.
Access and automated pass
days 1–2
Repository access, dependency and licence scanning, secrets detection, complexity and duplication measurement, infrastructure configuration review. Anything resembling a walk-away item is escalated that day, by telephone.
Engineering review
days 2–7
Engineers read the system: authorisation coherence, data model integrity, service boundaries, release and rollback, and what the roadmap in the plan would actually require. This is where the findings a committee has not guessed come from.
Management interviews
days 4–8
Structured sessions with the founder, key contributors and whoever owns infrastructure and releases. Collaborative rather than adversarial, and consistently the most valuable material in the report.
Report and committee walkthrough
days 8–10
The written report, the costed findings register, and a live session with whoever has to defend the recommendation, including the version aimed at non-engineers.
Red flags do not wait for the report. You receive the findings register as it develops. If something on day two changes whether you proceed, you hear it that day.
Five days versus two weeks. A five-day engagement covers the automated pass, a targeted read of the highest-risk subsystems, the dependency and licence position and one round of interviews. It will surface most walk-away and price-affecting items. It will not produce a defensible integration cost, a full architecture view, or a considered assessment of a team beyond its principal. Where the timetable allows only five days, the report states what that scope left uncovered, so nobody mistakes silence for a clean result.
What you receive
- An investment-committee summary of three to four pages, written for people who will not open the technical appendix, stating what the asset is, what is wrong with it, what that costs, and which findings are walk-away, price-affecting, condition or post-close.
- A full technical report against all nine dimensions, with a status for each and the evidence behind it, so an adviser on either side can follow the reasoning to source.
- A costed findings register in which every material finding carries a location, a business consequence in plain language, a remediation estimate and a deal classification.
- A dependency and licence inventory covering every direct and transitive package, its version, source and licence obligation, in a form that goes straight to counsel.
- A code provenance assessment covering the controls applied to AI-generated code and the contributor and contractor agreements behind the asset.
- A key-person and team assessment showing where knowledge concentrates by module, what the interviews established, and what must be true for the plan to survive a departure.
- An integration cost estimate for trade buyers, covering identity, data migration, platform consolidation and your internal security baseline.
- A 100-day technical plan, optional and priced separately, setting out what the first fourteen weeks of ownership contain, sequenced by risk.
- A live walkthrough, recorded if you want it, so committee members who missed the call get the same account.
Independence, conflicts and confidentiality
We act for one party in a transaction.
Whoever instructs us receives the findings, and nobody else does. We will not run buy-side diligence and sell-side preparation on the same deal in either order, and we take no second instruction on a transaction we are already engaged on.
We disclose prior contact before we accept.
If we have previously audited, remediated or built anything for the target or the acquirer, we say so at instruction and you decide whether it is acceptable. Prior knowledge usually sharpens a review, but that is your judgement rather than ours to withhold.
Our fee does not depend on the outcome.
It is agreed against scope before work starts and is the same whether the deal completes, is repriced or collapses. A provider paid more when a transaction closes is not giving you an independent view, whatever the report says.
Target material is handled as the target's.
Read-only repository access, no production data, no customer records, named reviewers listed in the engagement note, access revoked on delivery. Source material is deleted on completion; we retain the report and register only.
We tell the target what we are doing.
Interviews are conducted openly and we do not misrepresent the purpose of a question.
What changes afterwards
The committee paper stops relying on impressions.
A named engineer's assessment, costed and classified, holds up under challenge in a way a good call with the founder does not.
Negotiation moves onto evidence.
A remediation estimate in engineering months and money is a position that can be discussed. “The code seemed messy” is not, and it produces an argument neither side wins.
The first hundred days start with a plan instead of a discovery phase.
New ownership typically loses its first quarter working out what it bought. A plan written during diligence removes most of that, built from evidence gathered while the seller was still explaining things.
On the sell-side, surprises stop deciding the process.
Deals slow over things nobody saw coming far more often than over problems both parties understood from the start. Finding your own issues turns them from bargaining chips into line items.
Everyone learns what the team is.
In an AI-built asset, that is often the finding that matters most.
Why Noseberry
We read AI-built systems for a living.
This service line exists because we audit, remediate and build software produced with AI tooling every week. A generalist provider reading its first heavily generated codebase spends the engagement learning what normal looks like here. We already know which anomalies are worth a paragraph.
Engineers who have operated systems.
Everyone on a diligence engagement has shipped and carried production software. That is the difference between a report that identifies a risk and one that can price its removal.
The same framework as every other assessment we run.
A target is measured against the dimensions used in an AI Code Audit or a Production Readiness & Hardening engagement, so a post-close reassessment measures what the diligence measured.
We write what we found, including nothing.
Some assets come back in better condition than the buyer expected, and we say so in the same plain terms we would use for a problem. A provider whose reports always justify their own fee is assessing nothing.
We stay inside our competence.
Engineering findings, costs and risks. Not valuations, not legal opinions, not a view on whether to do the deal.
Frequently asked questions
Ten working days is the standard engagement for a single-product asset: scoping on day zero, automated analysis in the first two days, engineering review across the middle, management interviews from day four, and the report and committee walkthrough by day ten. Compressed five-day reviews are common and we run them regularly. Multi-product estates, or targets with several repositories and separate infrastructure, usually need three weeks. Whatever the length, the findings register is shared as it develops, so nothing material waits for the document.
Consistently: authorisation controls applied in most places and missing in a few, because features were added in separate sessions with no shared standard. Data models built for the demonstration and never revisited. Three implementations of the same logic in different styles. Dependency trees nobody has inventoried, sometimes carrying a licence obligation the team is unaware of. Deployment that consists of one person and one laptop. And, most often, knowledge concentrated in the single contributor who is also why the delivery chart looks impressive.
Yes, and it is a substantial part of what we do. We run the same review a buy-side team would run, deliver it only to you, and sequence the findings by what is material and fixable inside your timetable. We also tell you which items a competent counterparty will find, and roughly when. The best time to commission it is six to ten weeks before a data room opens, while there is room to close things rather than only explain them.
No. We are engineers, not lawyers, and nothing in our reports is legal advice. What we provide is the factual basis your counsel needs: a complete dependency inventory including transitive packages, the licence attached to each version in use, where each component sits in the product, which obligations are triggered by how the software is distributed or hosted, and what replacing a problematic component would cost in engineering time. Counsel forms the opinion. We make sure it is not formed from an incomplete list.
Yes, and on an AI-built asset it is often the more valuable half. We combine repository evidence, such as authorship concentration by module, review participation, commit shape and incident patterns, with structured technical interviews of key contributors. The interviews test whether someone can navigate and change code they did not recently write, which is the capability that decides whether the roadmap survives the transaction. We report concentration and named gaps rather than scoring individuals, and we are explicit about the limits of what any of it proves.
No. We produce the technical inputs a valuation uses: remediation effort in engineering months converted at a rate you nominate, integration cost where there is an acquirer, and a classification of each finding as walk-away, price-affecting, condition or post-close. Each carries its reasoning, so an adviser can test the estimate rather than accept it. What that means for consideration is your decision. Providers who deliver a number tend to deliver the number their client's position implies, which is what a committee should be sceptical of.
Read-only access to the repositories in scope, or a supplied archive where policy requires it, plus read-only cloud console access for the infrastructure review. No production database access, no customer records, no credentials to live systems. We also need two to three hours of the founder's or CTO's time, access to key contributors, and sight of the contributor and contractor agreements behind the codebase. Everything runs under the transaction NDA, access goes to named reviewers only, and it is revoked on delivery.
It happens, particularly where the buyer is also a competitor, and it is not automatically a red flag. There are workable arrangements: analysis run inside the target's environment with only findings exported, a clean-room review by one named reviewer under separate terms, or a staged release of repositories as exclusivity progresses. What we will not do is write a report implying coverage we did not have. Any restriction is stated in the report, alongside what it stopped us assessing and how much that matters.
Never on the same transaction. Whoever instructs us receives the findings and nobody else does, and we will not take a sell-side preparation and a buy-side review on the same asset in either direction. Any prior engagement with either party is disclosed before we accept, and you decide whether it is acceptable. Our fee is fixed against scope and does not change with the outcome, so nothing in our commercial position depends on the deal completing or on the report reading a particular way.
Yes. The 100-day technical plan is an optional deliverable that turns the findings register into a sequenced fourteen-week programme, weighted by risk rather than by what is easiest to start. Where the buyer wants execution, remediation runs through Vibe Code Cleanup or an architecture engagement using the same framework, so a reassessment six months later measures what the diligence measured. Several acquirers commission the review and the first hundred days as one piece of work, which keeps the engineers who read the code on the problem.
Get a technical view you can defend
Tell us the shape of the transaction and the date the timetable ends. We come back within one working day with a scope, a fee and an honest view of what a review of that length can and cannot cover.
Related resources
Go deeper with our thinking
From Spreadsheets to a Scalable Platform – building Canada’s Most Tenant- First Coliving System
Read case study
How to Build a SaaS Product
Read guide
The MVP Development Guide
Read guide
Building a Digital Engineering Roadmap That Aligns With Business Goals
Read article
Engineering IoT Products: Key Challenges and Best Practices
Read articleNot sure where you stand?
Take a free two-minute readiness scorecard built for your industry.