Chances are that in your position as tech leader, you’ve performed technical due diligence on another company.

Or maybe you’ve been on the receiving end, having to answer enquiries from consultants or fellow tech leaders.

Lastly, you might be among those who have never taken part in such a process ever, and you might even wonder what the hell technical due diligence is.

If you’ve always been afraid to ask for fear of looking dumb, you have two options. Linger in your secret ignorance, hoping nobody will find out, or keep reading¹.

What is Technical Due Diligence?

Wait, we’re always told we need to start from the business. So, let’s discard the technical bit for a moment, and let’s focus on the overall concept.

What’s due diligence?

Here is how the Merriam-Webster dictionary² defines it in the business context:

research and analysis of a company or organization done in preparation for a business transaction (such as a corporate merger or purchase of securities)³

In layman's terms, that describes the process you go through to make sure you’re not going to make a shitty deal.

Similar to what you do when you check price-comparison sites⁴ or when you examine reviews on Amazon before buying a €20 item from an unknown vendor. Or when you read the fine print before signing up for an insurance contract.

Except that in this case the stakes are slightly higher, and you usually would not find the answer to your questions by browsing public websites.

When you’re running a Due Diligence (DD), it generally means someone has a serious intention of acquiring another company through an M&A⁵ type of operation. Such deals typically involve amounts ranging from hundreds of millions to billions of euros⁶, and their outcomes can have significant consequences. Every “deal” typically attracts multiple bidders competing for the opportunity to snatch a great bargain.

More importantly, even though everyone in the industry knows exactly what is going on, who is talking to whom, which offer is most likely to be accepted, who is really going to benefit from it, etc., the whole process has to run behind a facade of confidentiality and secrecy.

The main reason is that leaks could be cause for serious market manipulation. I’ve heard that’s illegal, and you don’t want to find yourself at the receiving end of a lawsuit for breach of confidentiality.

Oh, and this is not legal advice⁷.

Despite the official reasons for maintaining confidentiality, I suspect that some software vendors have a vested interest in perpetuating the illusion, particularly those who sell digital solutions that sound much more exciting and prestigious than they actually are.

A prime example of this is the data room⁸!

The Data Room

When will the data room be open?

That’s one of the most frequent questions you hear when you start a due diligence process.

You typically get bonus points for being the one asking it, as it signals your familiarity with the lingo and projects you as a veteran in the process.

Technically, it should be called VDR, or Virtual Data Room, but we most commonly refer to it as Data Room.

When I first heard the term, my imagination went wild.

I was picturing a room inside a central-bank-style vault, bright light illuminating lines of racks of humming servers. Blue and green LEDs pulsing rhythmically at the pace of data being read and written on the storage.

At a desk, a white-coat technician vaguely resembling Alan Turing would hand you a menu from which to order your favourite piece of data, or you could just go for the data du jour.

Needless to say, like all nerdy phantasies, this one too turned out to be very inaccurate.

In reality the Data Room is an (expensive) web application that does the following:

• It allows the two counterparties to upload documents related to the deal being discussed

• All data is encrypted

• They keep a full audit trail of all the data accessed: by whom, when, how often, etc.

• Documents are watermarked in case someone takes screenshots or downloads the files

In essence, it's a file-sharing system with bolt-on extra security.

There are obviously a lot of compliance-related reasons to do so.

These reasons include keeping track of the data exchanged between the two (or more) companies and identifying who had access to a specific document in case of a leak.

It’s a pretty simple job to do, but VDR vendors seem to find a particular satisfaction in offering those capabilities with a UX that’s a hybrid between Microsoft Access and Craigslist.

If that doesn’t sound too terrible, please note that the way data is organised seems to have been invented by someone in love with SNMP OIDs⁹.

I suspect that someone is sitting in a room twisting their moustache, secretly enjoying making life even more miserable for folks already burdened with the need to go through an arguably tedious process.

I guess the VDR space can be qualified as a market ripe for disruption. But I digress.

In essence, the data room is where you publish or retrieve all the information that has been requested as part of the due diligence process. The data room is generally open for a set amount of time, and one or more consultancy firms are involved with governing who has access to what, what can be asked, and how many questions you’re allowed to ask.

More importantly, they’re there to ensure you only use the VDR to communicate. No emails, phones, or pigeons. Every live meeting between the parties has them present, sitting in silence, observing, and ensuring the respect of boundaries.

A bit like traditional parents who sit in rooms while their children date potential partners. I always perceive a weird mix of voyeurism and oppression involved with both approaches.

Now that you know all there is to know about the data room, let’s go back to the main topic of today’s article: running a tech due diligence.

Enters the Technical Due Diligence

A full due diligence process tends to cover multiple dimensions and angles of the target company, including but not limited to its financial situation, commercial strategy, product metrics, organisational setup, and technical platforms or assets.

By chance, duty, or punishment, you’ve been selected to run or participate to assess the technical dimension, what’s generally referred to as the tech due diligence.

What do you do?

You could wing it and ask a chatbot to give you the plan, collect all the data it suggests you do, violate all the restrictions by updating it to some AI-powered document processing repository, and have it generate a report. That’s not the approach I’d recommend, unless you really want to ensure you won't be asked to do it a second time¹⁰.

The first thing you want to do at this stage is to understand the nature of the deal. Not all deals are born equal, and some are even born less equal than others.

Broadly speaking, when it comes to M&As involving technology companies, you could group them in the following categories:

• Acquiring brands and clients. This is often the case when the two players are competitors in the same space. The target company has a strong position in a certain market or region, and that’s the only thing you want to incorporate. You have platforms, employees and knowledge in-house, but instead of spending years and marketing money to build up the position, you want to buy an existing one.

• The goal is to acquire the company and maintain its independent operations. This is often the case when the buyer is an investment fund, PE or conglomerate with a diversified portfolio. They have money to invest, and they think your company makes for a beneficial addition.

• Acquire the company and integrate it with its existing structure to capitalise on synergies. Similar to the previous scenario, the buyer in this case is interested in the complete package. This is a common case with incumbents buying the rising startup with an innovative product or two major conglomerates merging to consolidate their complementary market positions at the regional or world level.

• Acqui-hiring: The folks in big tech and Silicon Valley popularised this approach. See the recent acquisition that Google made of “Windsurf”¹¹, or Meta acquiring Scale AI. One of the key drivers is to buy smart people with specific domain knowledge and have their company come as a nice benefit.

• It’s unclear who suggested leaning into the deal. This is the worst case. Nobody knows exactly why they’re willing to make the deal, yet there’s a clear intention to proceed. If you’re in this case, good luck. Chances are that none of the work you’ll do in the DD will matter. But you can still learn a lot through the process.

This is a broad categorisation, and no deal will fall perfectly within the boundaries of one specific category. However, every deal typically veers towards one or the other.

What matters is that your analysis and investigation on the technical side will vary widely depending on the investment thesis. What you’ll be looking for when acqui-hiring will be very different from what you’ll be interested in if it’s a matter of acquiring a brand and clients.

These principles might sound obvious, but it’s not uncommon to see people apply a blanket approach because that’s the one they’ve been taught to follow, without even doubting it might be the most relevant.

What to look for in different cases

At this point you might be wondering if I have anything non-obvious to offer, and I hope that what follows will satisfy that.

Let’s look again at the categories above and see what should be in scope and what can largely be ignored when conducting technical due diligence.

We’ll look at the 4 defined cases, leaving the last “undefined” one out, as that would be the case where applying a by-the-book approach would be the most appropriate strategy.

Acquiring Brands and Clients

In these types of deals, it is crucial that your company's intention to absorb the client base and brand position will not be screwed by unforeseen surprises. Usually, limited technology plays a role in this process, but it can become an obstacle in the most complex scenarios.

In Scope

• Security and Compliance Risks
  The day the acquisition is signed, you’re accountable for compliance and security practices. Furthermore, a vulnerability in the acquired company could become a Trojan horse into your entire organisation.

• Data-in / Data-out
  Chances are that you’ll want to get the customer’s data out of the target system and into your company’s. It’s worth paying attention to how the data model is structured and how easy or hard it would be to get data in and out of the system. This includes traditional back-office systems such as ERPs and CRMs.

• Platform Health
  You will have to run the target company's systems for a while before shutting them down. You want to get a decent sense of the operational and maintenance overhead that might be caused by instability, technical debt, and bad practices. The goal is not necessarily to plan an investment in modernisation, but rather to understand the full operational cost of internalisation.

• Operational Costs
  Particularly, what would be the bare minimum cost associated with keeping the lights on (KTLO)? Are there expensive vendors or old systems that need urgent replacement to be accounted for?

Not So Relevant

• Talent and Skills.
  This is not what your company is buying. As cynical as it may sound, the intention might be to lay off most of the personnel. Still, you want to get a decent sense of who the key people are with the institutional knowledge needed through the decommissioning phase.

• SDLC.
  You’ll probably need close to zero changes besides pure maintenance. A perfect SDLC process at this stage offers minimal gains. The security and compliance section will likely raise major red flags related to engineering practices and processes.

• Overall technology platform.
  As you don’t plan to invest in the platform, you’ll care very little about the stack used, architectural patterns, evolvability, etc. In particular, the affinity or distance between the target systems and your company’s systems is of little relevance here.

• Scalability and performance.
  Unless there are major stability issues caused by poor performance under load, you should not care too much about this aspect.

Acquire a Company to Keep it Running Independently

The most important thing to validate here is that the company can keep operating and growing on the current foundations for the foreseeable future. And if that’s not the case, flag all the major investments required to secure it.

In Scope

• Security and Compliance Risks.
  I won’t repeat it further, but these are always in scope. Don’t skip it.

• Talent and Skills.
  Very important. You want to ensure the company has the right mix of people and culture to take them to the next steps. You’ll also want to look at efficiency and organisational complexity.

• SDLC.
  Very important, for the same reasons as above. You want to ensure the company is operating on robust and sustainable principles and practices.

• Overall technology platform, health, scalability & performance.
  Though you would not care much in terms of affinity with other companies in your portfolio, you want to ensure the stack is based on proven technologies and that it follows the appropriate architectural approaches to ensure the company’s growth in the upcoming years. If not, this is an area where you might have to flag required investments.

• Operational Costs.
  You want to get a good understanding of the cost structure, FinOps practices in place, and potential optimisations. Are there vendors for which your company could provide more cost-effective alternatives?

Not So Relevant

• Data-in / Data-out. Since there is no intention to integrate the company’s operations with other activities in the portfolio, this aspect becomes less relevant. An exception is made if you’re planning to pursue integrations with a significant number of third parties.

Acquiring a Company for a Full Integration

The primary concern here is the cost and effort involved: how long will it take, and how challenging will it be, to fully integrate the target company's systems into our own platform, thereby achieving the best possible outcomes? It is not easy to answer precisely, given the level of detail available in a DD process, but you are still requested to provide an indication.

In Scope

• Security and Compliance Risks.
  Have I mentioned this topic previously?

• Talent and Skills.
  Very important. You want to make sure the culture and the mix of talent are compatible with the ones at your company.

• SDLC.
  This is crucial for the same reasons mentioned above. The bigger the distance between the two companies, the more cumbersome and chaotic the integration will be.

• Overall technology platform, health, scalability & performance.
  This is where assessing affinity or distance becomes key, as this will be one of the key drivers for the integration effort. The differences will have to be assessed both from a pure technical standpoint (stack, architecture, tooling, vendors, etc.) as well as from a business logic perspective: data models, life cycle of the key business entities, commercial products and relative business model, etc.

• Operational Costs.
  Here you’re looking for both investments based on your current stack and ways to leverage more efficient solutions available in the target company.

• Data-in / Data-out.
  Since you’ll be expected to converge on the data eventually, this aspect becomes crucial. You want to get a clear understanding of how easy or difficult it’ll be to move data around across the two entities as they progressively merge into one.

Not So Relevant

I’m sorry to say that very little is out of scope here.

Perhaps the primary colours used in the design system.

Acqui-hiring

I do not have direct experience with this type of operation. Therefore, my recommendations here are more speculative than experience-based.

In Scope

• Security and Compliance Risks.
  Unless you’re effectively shutting down the company’s services on the acquisition date, you’ll want to know what risks you’re exposing your company to.

• Talent and Skills.
  This is the most important aspect, and it is likely that someone has already completed a significant portion of this work prior to the discussion. You’ll want to spend a lot of time mapping out all the talents in the target company.

• SDLC.
  Partly relevant, as it’s a manifestation of the talent, skill and culture in the organisation.

Not So Relevant

• Overall technology platform, health, scalability & performance.
  You just want to make sure that there aren’t surprises here suggesting that the so-called talent has been overselling their skills.

• Operational Costs.
  Same as above.

• Data-in / Data-out.
  Largely irrelevant.

Do you want to know more about the details?

After defining the scope of the assessment, you must determine the necessary steps to execute it.

Let me know in the comments section below if you'd like a follow-up article that explores the details of the execution.

In the meantime, if you're someone that identified themself as a Woman In Tech, you might want to have a look at the promo below.

WIT Promo for Q1 2026

I’ve recently decided to resume offering quarterly promos for people who are willing to benefit from my services.

I’m happy to announce that I’ve opened up the Q1 promo that will run until the end of March 2026.

I’m making it easier for Women In Tech to level up their engineering leadership skills by offering an exclusive discount to the Sudo Make Me a CTO: 30% off for the first 12 months.

You can find out all the details at the official promo page, or by clicking the button below.

WIT Promo 2026

Feel free to share this opportunity with people you know, and do not hesitate to reach out if you’d like to learn more about it.

You can always schedule a free 30-minute session to get all your questions addressed.

Looking forward to seeing the community grow with more diversity.