Technical due diligence on a software acquisition works differently before and after the letter of intent (LOI). A pre-LOI screen is a lighter review that helps you decide if to bid in the first place and at what price. It pays off only when the seller grants access before the offer. A post-LOI confirmatory audit runs during the exclusivity window with full access to the codebase and team, verifying the seller's claims and pricing any risk into your offer. For most software deals, run both, scoped to the stage. MEV runs either, buy- and vendor-side, for a fixed fee in the $5,000 to $30,000 range, in two to four weeks.
You're acquiring a software company, and you have a decision to make about diligence spend. Order a deep technical audit too early and you can burn $20,000 reviewing a target that dies in negotiation. Start too late and you lose part of the exclusivity window you negotiated for diligence. You can avoid both by scoping the review to the deal stage.
MEV runs buy- and sell-side technical due diligence (TDD) on software targets, with senior engineers doing the review hands on.
Pre-LOI vs Post-LOI Technical Due Diligence: What's the Difference?
Each stage has a different objective. Pre-LOI, technical due diligence is a light screen to decide whether to bid at all in the first place.
Post-LOI, it becomes a confirmatory audit that verifies what the seller claimed. In both cases, it's an engineering review of a target's codebase and infrastructure, and the deal stage dictates how deep this audit goes.
The stage sets the boundaries: what you can see, how deep you can go, and how fast you have to move. A letter of intent (LOI) sets out proposed deal terms such as the price range and structure. While the agreement is non-binding, the exclusivity and confidentiality clauses still hold.
The exclusivity period is the window, set by the LOI, when the seller agrees not to talk to other buyers. It runs 30 to 90 days in most mid-market deals, which gives you a fixed clock for the deeper review. MEV's two-to-four-week audit is built to fit inside it.
The seller controls the access gates. A competitive seller guards the codebase before the LOI and opens the systems only once exclusivity makes you the sole buyer.
Should You Run Technical Due Diligence Before the LOI?
A pre-LOI screen is worth it if the seller shares enough to expose a deal-breaker early. It is a wasted budget in a competitive auction where systems stay locked until an LOI is signed.
Does the deal size justify a pre-LOI screen?
Deal size is the first filter. A pre-LOI screen sits at the light end of MEV's $5,000 to $30,000 technical due diligence price range, and where it lands depends on how much the seller opens up. A screen over one repository and a call with the founder costs less than a review of the full architecture.
On a small deal, this fee might cost more than the problem it uncovers. Plus, you have to pay it before you even decide to bid.
On a larger deal, a screen that catches one deal-breaker costs next to nothing compared to the check you're about to write. KPMG reports that 62% of deals fail to meet their financial objectives, with poor due diligence cited as the main reason.
Does the sale process allow pre-LOI access?
In a competitive auction, the seller guards the codebase until exclusivity, leaving little for a pre-LOI screen to evaluate. An off-market deal is different. The seller often lets you see more before you commit, which makes a screen worth running.
How much risk are you carrying into the bid?
A pre-LOI screen is there to help you decide what to offer. If the code looks solid, you can bid at the price the seller is asking. If the screen turns up a problem, that's your reason to open lower or even walk away from the deal.
What Does a Pre-LOI Technical Screen Cover?
A pre-LOI technical screen is a document-led review that tests the technical assumptions behind your bid. You work from what the seller hands over with the codebase still closed, plus a call with their engineers.
.png)
What can you ask the seller for before the LOI?
Most sellers release the items below under an NDA, with the repository still closed:
- An architecture overview.
A diagram or a walkthrough call covering the main services and the third-party systems the product leans on. - The stack and the hosting bill.
Languages, frameworks, cloud provider, and twelve months of cloud invoices, since one month's bill won’t reveal the trend. Hosting spend that climbs faster than revenue can become your margin problem after close. - Security artifacts the seller already holds.
The latest penetration test report, where an outside firm was paid to break in and wrote up what worked, and what didn’t. - Independent security audits.
Whether an outside auditor has checked how the company protects its customer data. In the US that check produces a SOC 2 report. Elsewhere it is often an ISO 27001 certificate.
A SOC 2 comes in two kinds. A Type I confirms the security controls existed on the day the auditor looked. A Type II confirms the auditor watched those controls run for three to twelve months, and it lists every one that failed in that window. - A dependency and license inventory.
A software bill of materials (SBOM) lists every piece of code inside the product that the company did not write itself, with the license on each piece. Most of it is open source. Sellers who don't keep an SBOM can submit a build tool lockfile like package-lock.json instead. These files automatically log every single package a product uses.
So, the lockfile names the packages. We look up the license on each one. A lockfile covers a single language, so a product written in three languages has three of them, and we want all three.
But lockfiles only catch what the product downloads automatically. If a developer copies code in by hand, the lockfile misses it completely. That kind of manual copy only turns up when an auditor scans the source code after the LOI. - IP chain of title.
The paperwork proving the company owns the code it's selling. Whoever writes the code owns it, unless they were an employee at the time or explicitly signed the rights away. If a founder built the first version before incorporating, they own it personally. If a freelancer built a feature and just sent an invoice, they still own that feature.
You want to see the papers handing that work to the company. Without them, your lawyers will likely freeze the deal while the seller tracks down a freelancer from a few years ago. - A demo led by the CTO or the lead engineer, with your reviewer on the call.
The call needs to answer two things: what breaks at 10x scale, and which parts of the system the team actively avoids. - Team shape.
Headcount and seniority, plus how much of the system’s knowledge sits in one person's head.
The license inventory takes an afternoon to review and it usually surfaces deal-breakers.
Like everyone else, the company uses free, open-source code. Most of it is harmless, but some packages come with a rule: if you use them, you have to make your entire product's source code public.
This is called a "copyleft" trap. It usually triggers via the GPL license, or the even stricter AGPL license, which legally requires you to open-source your entire product the moment a user accesses it over the internet.
If the target company built their software on top of those packages, the code you are buying isn't private anymore. Anyone who uses the product can demand a copy of the source code. That finding goes straight to your lawyer.
Black Duck's 2026 OSSRA report found license conflicts where open-source rules clash with how the company sells its product in 68% of the 947 commercial codebases it audited. That is up from 56% a year earlier, making it the largest one-year jump in the report's history.
The seller's response to this question is itself informative, too. Early in a broad auction, a seller may be managing ten bidders at once, so a slow reply is understandable. But once you're short-listed and the seller still refuses to hand over their license data, it’s a red flag.
What can you skip until exclusivity?
- Full repository access and commit history.
A competitive seller opens the code once exclusivity removes the other buyers. - Static analysis and code quality scans.
These tools read the code without running it to flag security holes and dead code. Because they need full access to the codebase, they usually wait for the post-LOI confirmatory audit.
There is one exception though: some sellers will let a third-party auditor run the scan under NDA and release only the report, so you get the findings while the code stays closed to you. - A penetration test against production.
You run these tools only with the seller's written permission and during a scheduled window, which comes with exclusivity. - Interviews with individual engineers and customers.
Morgan & Westfield advises sellers to resist opening up employees and customers, and to hold that access until the purchase agreement is close to signed, so expect it late in the process. - Cloud console and CI/CD access.
Read-only credentials arrive with the confirmatory audit.
Two core questions decide what you should ask during pre-LOI: What will the seller actually give you during this window? And what would make you lower your price if it came back with some red flags?
Everything else can wait for the post-LOI audit.
What is Confirmatory Technical Due Diligence?
Confirmatory technical due diligence is the deeper, post-LOI audit that checks whether the target is what the seller said it is. With full access to the codebase and team, this review verifies the technical claims and flags anything that should change the deal's price or terms.
A confirmatory finding rarely kills a deal on its own. More often, it gives you a number to negotiate with. When the audit puts a cost on a risk, say the work to close a security gap or to rebuild a component that won't scale, that figure becomes a price chip you take into the purchase agreement.
Buyers usually turn a confirmatory finding into one of a few outcomes:
- A price reduction: Lowering the purchase price to absorb the cost of the fix.
- An escrow holdback: Retaining a portion of the purchase price in escrow to fund the fix.
- An indemnity: Keeping the seller legally liable for that specific issue post-close.
- An earn-out adjustment: Tying part of the final payout to the technology's actual performance.
If a technical risk runs so deep that it cannot be priced, that same audit provides the hard evidence you need to walk away before closing.
What Does Technical Due Diligence Find?
Technical due diligence surfaces the risks that change what a target is worth: the aging systems and security gaps a seller may not have flagged. When a seller downplays tech debt, the buyer’s engineering budget pays for it long after the deal closes.
For instance, McKinsey found that companies divert 10 to 20% of the technology budget meant for new products to servicing tech debt they already carry.
Each risk comes back rated and priced, so you know what you'd spend to fix it.
A recent MEV engagement shows how that works. The seller was keeping system access low, so the team captured endpoint versions and patch levels by running diagnostic scripts remotely, without touching production. The team filled in the rest through stakeholder interviews and vendor documentation.
The review found about 14 aging workstations, some still running Windows 7. The network had no segmentation, and backup coverage couldn't be confirmed.
We rated the target Moderate Risk for operational continuity and Elevated Risk for cybersecurity.
Under a $25,000 materiality threshold, the dollar line below which a finding doesn't affect the idea, the operational continuity risks fell under the line and didn't impact the deal. However, the cybersecurity risk checked out higher due to aging endpoints and limited network visibility.
To address this, we provided the buyer with a staged, costed upgrade path for the first 12 to 18 months, moving from immediate fixes to later modernization.
What Should You Prepare Before You Scope a Review?
Before you talk to a provider, have these ready:
- Deal stage: pre-LOI or post-LOI, and whether an exclusivity clock is running.
- Deal size and type: roughly how large, and whether it's an auction or an off-market deal.
- The post-acquisition strategy: whether you intend to integrate, scale, turn around, or simply hold the company.
- Your primary risk concern: security, scalability, or key-person risk if one founder holds all the knowledge.
- Timeline: when you need findings, and any hard date you're working against.
- Access: what the seller will open up right now, from a demo and docs to full code and infrastructure.
With those in hand, MEV or another software due diligence company can tell you if you need a pre-LOI screen, a post-LOI confirmatory audit, or both.
Can Sellers Run Technical Due Diligence Too?
Yes. Vendor-side software due diligence is a seller's own TDD, run before going to market to find and fix the issues a buyer's audit would flag. A clean report supports the asking price and leaves the buyer fewer findings to negotiate the price down with.
This works best when the seller starts early enough to fix what the review turns up. Closing those gaps ahead of time removes the buyer's leverage to retrade before the deal reaches exclusivity.
MEV runs vendor-side reviews as well as buy-side ones. If you are preparing to go to market, we can audit the codebase on the same terms a buyer's team would, so you see the findings first.
Bottom Line: Pre-LOI, post-LOI, or Both?
For most software deals, we recommend running both, scoped to the stage. A pre-LOI screen shapes your bid, and it's worth running only when the seller grants some access before the offer. The confirmatory audit belongs in the exclusivity window, where full access lets you verify the claims and price the risk.
On a smaller or off-market deal, you can fold both into a single post-LOI engagement. So, you're scoping against access: how much the seller grants, and when.
MEV runs technical due diligence on both sides of a deal, buy-side and vendor-side, in SMB and lower-middle-market software M&A, with extensive expertise in healthcare, data, and AI systems.
If you need some help pre- or post LOI, tell us where the deal stands and what the seller will open up right now. We'll scope the review to the stage and fit it to your timeline.
At MEV, we've received this question from buyers on a few M&A software deals: should technical due diligence happen before the letter of intent, or after? An audit ordered too early can burn the TDD budget on a target that doesn't necessarily make it through the negotiation. An audit run too late doesn't fully leverage the exclusivity window you negotiated for diligence. We wrote this piece to answer that question with the reasoning we use on live deals.
We built this article from MEV's own diligence work, the audits our senior engineers run buy- and vendor-side on software targets.
FAQ
Should you do technical due diligence before or after the LOI?
Both, for most software deals. A pre-LOI screen tells you whether to bid and at what range. A post-LOI confirmatory audit verifies the seller's claims and prices any risk into your offer and the purchase agreement.
What is confirmatory technical due diligence?
It's the post-LOI audit run under exclusivity, once you're the sole buyer with full access. Where the pre-LOI screen decides if to bid, the confirmatory audit prices what you found into the purchase agreement.
Can technical due diligence be done during the exclusivity period?
Yes. The exclusivity period is the standard window for the post-LOI confirmatory audit, and MEV's two-to-four-week timeline is built to fit inside it.
How long does technical due diligence take?
MEV runs most engagements in two to four weeks for a fixed fee in the $5,000 to $30,000 range. A pre-LOI screen sits at the lighter end. A confirmatory audit uses the whole window, and a complex target or restricted access can push it longer.
How much does technical due diligence cost?
MEV runs technical due diligence for a fixed fee in the $5,000 to $30,000 range, set by scope. A pre-LOI screen sits at the lighter end, and a full confirmatory audit uses more of the range. You know the number before the work starts.
Is there another technical check after the confirmatory audit?
Sometimes. On a longer or more complex deal, buyers run a light pre-closing review that confirms nothing material changed between the audit and the closing date. On most software deals the confirmatory audit carries the technical weight.
