By Mario Peshev, DevriX
You are three weeks from confirmatory diligence on a lower-mid-market SaaS or tech-enabled services target, and the technology read you have in front of you is a code-quality report that tells you nothing you can price. The seller’s data room has an architecture diagram, a list of frameworks, and a security questionnaire someone filled out defensively. None of that answers the question your investment committee will actually ask: does the technology support the thesis, and what will it cost in cash and time to make it support the thesis? A weak M&A technology assessment is not a gap in documentation. It is a gap in the number you underwrite the deal at, and it shows up eighteen months later as a missed integration date or a re-platform you did not budget.
I run these assessments for private equity buyers, and the pattern is consistent. The deal team does not need a technical inventory. It needs a decision. This piece lays out the framework I use to turn engineering reality into something a deal partner or operating partner can act on before signing.
Most technology assessments do not inform a decision
The failure mode is well understood by anyone who has sat through a diligence readout that ran long and resolved nothing. A vendor walks the room through repositories, cloud spend, ticket backlogs, and a heat map of “risks” color-coded red, amber, green. Everything on the slide is true. None of it is decidable, because none of it is tied to the thesis, the price, or a date on the plan.
A deal partner is underwriting revenue growth, margin expansion, and a path to exit. An operating partner is underwriting speed of integration and the repeatability of a playbook across the portfolio. Neither of them can do their job from a list of technologies. The bridge you need is from technical fact to commercial consequence: this dependency delays the add-on integration by two quarters, that architecture caps the pricing model you built into the model, this key-person concentration is a churn risk on the platform’s largest account.
Bain’s annual Global Private Equity Report has tracked for years how much of the return now has to come from operational improvement rather than multiple expansion or leverage. When value creation carries the deal, the technology that either enables or blocks that value creation is not a footnote in diligence. It is the diligence.
The rest of this article is the framework I use to keep the assessment decidable. It has four tiers, and they run in order, because each one is only worth doing if the one before it holds.
The four-tier M&A technology assessment framework
I structure every assessment as four tiers, from the question that can kill a deal down to the question that shapes the first 100 days. You do not treat them as equal. You spend your diligence budget top-down and stop drilling the moment a tier gives you an answer clean enough to underwrite.
Tier 1: Thesis fit
The first question is whether the technology can carry the value-creation plan the deal team wrote. If the thesis is “triple the customer base by moving upmarket into enterprise accounts,” the assessment has to establish whether the platform can support enterprise SSO, tenant isolation, audit logging, and the reliability those buyers demand. If the thesis is “roll up five regional operators onto one platform,” the question is whether this asset’s platform is the consolidation platform or a liability you inherit. A technically excellent product that cannot carry the thesis is still a bad fit for this deal.
Tier 2: Deal-breaker risk
The second tier is the short list of findings that justify a re-trade or a walk. Unlicensed or license-incompatible open source in a product you plan to sell. A single engineer who is the only person who understands the billing system. Customer data commingled across tenants. A dependency on a founder who is leaving at close. These are not remediation line items. They are facts that change the price or the structure, and they belong on the table before the LOI hardens.
Tier 3: Integration and cost to plan
The third tier converts the plan into cash and calendar. If your model assumes the add-on’s orders flow into the platform by month six, the assessment has to say whether that integration is a configuration exercise or a rebuild, and what it costs in engineering headcount and elapsed months. This is where most models are wrong, because the deal team estimated integration effort from the outside and the estimate was optimistic.
Tier 4: Day-1 readiness
The fourth tier is the shortest and the most operational: what has to be true by the day you take control. Access to production systems, a named engineering owner, a working deployment pipeline, security controls that will not fail the first customer audit after close. This tier feeds directly into the first 100 days plan.
Does the platform carry the thesis?
The mistake here is grading the technology in the abstract. There is no such thing as good or bad architecture without a thesis to hold it against. A monolith that ships a stable product to 2,000 SMB customers is fine if the plan is to grow that segment. The same monolith is a problem if the plan is to sell into regulated enterprise buyers who require per-tenant isolation the codebase cannot provide.
So the Tier 1 work starts from the value-creation plan and reads backward. I take each pillar of the plan, pricing change, new segment, new geography, new product, cross-sell, and ask what the technology must be able to do for that pillar to hit its number. Then I test whether it can. The output is not a grade. It is a mapping: this pillar is supported, this pillar needs a defined build, this pillar is blocked by an architectural constraint that no reasonable spend removes inside the hold period.
That last category is the one that matters most and gets found least. If a core piece of the thesis is technically blocked, you want to know before you sign, not in the second board meeting. This is the same discipline I cover in exit readiness, only run from the buy side: the gaps a future buyer will price down are the gaps you should price down now.
The findings that re-trade a deal
Deal-breaker risk is a short list by design. If your risk register runs to forty items, you have not prioritized, you have transcribed. The findings that actually move price or structure fall into a handful of buckets.
- License and IP exposure. Open-source components under copyleft licenses embedded in code you plan to distribute, or code written by contractors under agreements that never assigned IP. This is a commercial and legal exposure, and I flag it for counsel rather than opine on it, but the assessment has to surface it.
- Key-person concentration. One person who holds the operational knowledge for a system the business cannot run without. This is a churn risk and an integration risk at once.
- Security and data findings that fail a customer audit. Tenant data commingling, plaintext secrets, no access controls on production. These become the largest customer’s exit ramp the moment they do their own vendor review.
- Undisclosed technical debt that gates the thesis. A re-platform the seller knows is coming but has not scheduled, presented as “roadmap.”
The Securities and Exchange Commission has steadily raised expectations on cybersecurity disclosure for public companies, and that pressure flows downstream. A target that intends to sell to enterprise or public-company customers, or one you intend to take public, inherits those expectations. You can read the current posture through the SEC. The point for the deal team is simple: a security gap that is tolerable today can become a covenant or a lost account tomorrow, and the assessment should price that forward, not just describe it.
Turning the thesis into a cost and a calendar
This is where the assessment pays for itself. The deal model has integration assumptions baked into it, usually written by people who could not see the code. Tier 3 replaces those assumptions with estimates grounded in what the systems actually are.
The work is concrete. For each integration dependency in the plan, I establish the current state, the target state, and the path between them, expressed as engineering effort and elapsed time with the sequencing constraints named. An add-on that shares a data model with the platform integrates in weeks. An add-on on a fundamentally different stack, with its own billing and its own customer records, is a multi-quarter program that may need hires you have not budgeted.
The output feeds the operating plan directly. This is the difference between advice you can ignore and a plan someone is on the hook to deliver, a distinction I have written about in the context of an operational value creation consultant. A number in a diligence report that nobody owns after close is a number that will be wrong. The Tier 3 estimate has to survive contact with the team that will execute it, which is why I prefer assessments that connect to technology due diligence and the execution that follows rather than a report that ends at signing.
McKinsey’s work on private capital and value creation makes the same point in aggregate: the deals that outperform are the ones where the operating plan was specific and owned early. You can follow that research through McKinsey. Specific and owned early is exactly what Tier 3 forces.
What has to be true on Day 1
Day-1 readiness is small in scope and large in consequence. The assessment produces a checklist of the conditions that must hold the moment you take control, because a gap here stops the plan before it starts.
- A named engineering owner accountable from Day 1, whether internal, embedded, or fractional.
- Verified access to production, source control, cloud accounts, and deployment tooling, with credentials transferred cleanly.
- A working, documented deployment path so the team can ship a change in week one without archaeology.
- Security controls sufficient to survive the first customer audit after close.
- A short list of dependencies on the departing seller, with each one either retained under a transition services arrangement or scheduled to be replaced.
Where the target lacks the leadership to own this, the honest answer is often fractional or embedded coverage rather than a rushed full-time hire, which is the case I make for a virtual CIO and for a part-time CTO seat that enforces decision rules rather than just attends meetings. The assessment’s job is to say which coverage the asset needs, not to assume the org chart already has it.
Reading the output as a deal partner, not an engineer
The assessment is only useful if the readout speaks in your language. When I hand a deal partner the output, it resolves to four things, in this order.
- Go / no-go on thesis fit. Can the platform carry the plan, or is a pillar of the plan technically blocked?
- Price and structure impact. The Tier 2 findings that justify a re-trade, an escrow, a retention arrangement, or a walk.
- Cost to plan. The Tier 3 numbers that should be in the model and probably are not, with owners named.
- Day-1 conditions. The Tier 4 checklist that goes straight into the integration plan.
Notice what is absent. There is no framework inventory, no ticket count, no code-quality score presented as if it were a verdict. Those are inputs. A deal partner does not underwrite inputs. This is the same reason I argue that PE needs permanent digital capacity rather than advisory alone: an assessment that stops at observation, with no one accountable for the consequence, leaves the value on the page.
An illustrative scenario
The following is an illustrative scenario, not a client outcome, offered to show how the tiers resolve.
Imagine a platform SaaS business serving mid-market customers, with a thesis to move upmarket into enterprise and to bolt on two regional competitors. Tier 1 finds the core product is well built for its current segment but has no tenant isolation and no SSO, both of which enterprise buyers require. That pillar of the thesis is not blocked, but it is a defined build, roughly two quarters of engineering, and it belongs in the model as capex it was not carrying.
Tier 2 surfaces one deal-breaker: the billing and revenue-recognition logic lives in a system understood by a single contractor whose agreement expires at close. That is a retention and escrow conversation before the LOI hardens, not a remediation ticket after.
Tier 3 finds the first add-on shares the platform’s data model and integrates in a quarter, while the second add-on runs on a different stack with its own customer records and is a three-quarter program needing two hires. The model assumed both would land by month six. One will. The other reshapes the year-one integration plan and the operating budget.
Tier 4 confirms the deployment pipeline works but there is no engineering leader, so the plan carries a fractional CTO from Day 1 to own the enterprise build and sequence the two integrations.
None of those findings are visible in a code-quality report. All of them change either the price, the structure, or the operating plan. That is what an assessment is for.
What the assessment should and should not commit to
An M&A technology assessment is a commercial, technical, and operating document. It does not give legal, tax, or valuation opinions, and it should not pretend to. When Tier 2 turns up license exposure or a data-handling problem, the assessment flags it and routes it to counsel. When Tier 3 produces a cost, that cost is an input to the model, not a valuation.
What it must commit to is a defensible view of thesis fit, risk, cost, and readiness, grounded in the actual systems rather than the data-room narrative. The wider governance question, when a technology finding belongs to the board versus the operating team, is worth its own attention, and I have addressed it in the context of board technology advisors and hands-on builds. For the assessment itself, the discipline is to stay in its lane and be precise inside it.
The cost of skipping this is not abstract. PitchBook and S&P Global both track the widening gap between top-quartile and median deal performance, and technology sits on the wrong side of that gap more often than the model assumes. You can follow that data through PitchBook and S&P Global Market Intelligence. The assessment is one of the cheaper ways to keep a deal off the wrong side of it.
When to run it, and at what depth
Timing is a budget decision. Two triggers matter most.
Pre-LOI, you want a fast, thesis-level read: is there anything that should stop me from signing this, and does the technology plausibly carry the plan? This is a scoped, lower-cost engagement designed to protect you from a bad LOI, not to produce a full report.
In confirmatory diligence, with the deal live and a close date approaching, you run the full four tiers and produce the readout that feeds price, structure, and the first-100-days plan. This is the depth that changes the number.
The sequencing that follows, engineering, product, and revenue operations pulling in the same direction after close, is where the assessment either pays off or gets ignored. I have written about that alignment in aligning engineering, product, and RevOps for value creation and about how a first-two-weeks audit surfaces the same issues once you own the asset in the technology and revenue audit. The assessment done well before signing is the same work done early enough to still change the price.
Conclusion
A technology inventory tells you what the target has. An M&A technology assessment tells you what to do about it: sign or walk, at what price, at what structure, and against what operating plan. The difference between the two is whether the work connects engineering reality to enterprise value, and that connection is the entire job. Run the four tiers in order, spend your diligence budget top-down, and read the output as a deal partner rather than an engineer. Do that, and the technology stops being the surprise in the second board meeting and becomes a line you underwrote with your eyes open.
If you have a target in diligence or an LOI approaching, DevriX runs the scoped pre-LOI read and the five-day technology assessment that feeds price, structure, and the first-100-days plan. See how the DevriX private equity engagement works and bring us the deal you need read before you sign.
