Buying the Tech or Buying the Business? What a Good Tech Due Diligence Tells You

The answer that was too good to be true

In one Tech Due Diligence I was part of, the product handled payments. In our first walkthrough we asked a lot of questions about transactions. What happens if a payment fails halfway? How do you make sure the data stays correct?

The technology team had good answers. Every flow was safe, every failure was rolled back, the data always stayed consistent. The explanation was clear, confident and complete.

It was too good to be true.

So we asked for a code walkthrough focusing primarily on the payment flows. The safety checks were there in some flows and missing in others. The data did go wrong from time to time. It was fixed by hand whenever someone reported it.

The system worked. It just didn't work the way we were told.

Finding that kind of gap between the story and the system is why a Tech DD (Technical Due Diligence) exists. But finding gaps is not the same as giving good advice. A good Tech DD has to tell an investor what those gaps mean for the investment.

What are you actually buying?

Most of the Tech DDs we do are for private equity firms buying a company and venture capital firms investing in a growth round.

The questions are a little different in each case:

• A PE firm wants to know: can this technology carry the business plan we are buying into?
• A VC firm wants to know: can this technology, and this team, take the company to its next stage?

The method is the same for both these cases. What we pay most attention to changes with the investment.

But underneath those questions is a more basic one:

Are you investing in technology, or in the business?

Sometimes technology is an asset. It's the real differentiator and it is worth paying for. Sometimes the business is strong and the technology is only just holding it up.

Both can be good investments. But they are very different investments, and the investor should know which one they are making.

Investors don't need a list of everything that is wrong with the choice of technology and the quality of code. Every system has flaws, and a good technologist can always find more.

They need to know what they are actually buying.

What a good Tech DD should tell you

To make that call, a Tech DD needs to answer five questions.

1. Can the architecture support the growth plan?

We need to assess the technology for where the business is going, not only where it is today. A system that works well today may become expensive or difficult to run as the business grows.

If the technology needs to be rebuilt to support that growth, the investor needs to know what that will take and what it will cost.

2. Can you trust the data?

If transactions, balances or records can quietly go wrong, that is a business risk, not only a technical one.

The payment flow issues I described at the start are the kind of problems that can surface in the first 100 days after an investment—issues that a good Tech DD should help uncover before the deal is done.

The investor needs to know whether the data can be trusted, whether important transactions can be traced, and whether the controls the team describes actually exist in the system.

3. Does the business depend on a few people?

A lot of the time you are investing in people.

We need to know whether knowledge lives only in someone's head, whether decisions all go through one person, and whether the team has the skills to build and run the technology as the business grows.

None of this shows up in the code, and all of it can become a bottleneck when the business tries to grow.

4. Is the product built for users and aligned with the business?

Good technology with a poor user experience or a confusing service design will struggle to scale, both in users and in the operations team supporting them.

We also need to know whether the roadmap is agreed with the key business people. A roadmap that is not aligned with business priorities is a concern.

The technology needs to support where the business wants to go, not just where the product happens to be today.

5. Does the team know where it cut corners?

Every team cuts corners under business pressure. That is normal.

The important thing to gauge is whether the team knows where those corners are, and whether they keep a proper backlog of the technical debt they need to pay back.

A team that can say "we did this well, and here is where we took shortcuts and why" is usually a team you can trust.

When that awareness is missing, it tells you where the team needs to grow.

A good Tech DD also tells the investor what they are paying for. What are the real differentiators in this platform? Most reports list only risks. The strengths equally matter to inform their decision. In some cases, the right call can be a “No Go”. In others, a “Go” with investors knowing the technology gaps, with a roadmap and a view of the cost.

How do you get to those answers?

The questions raised above sound straightforward. The difficult part is answering them fairly.

When you are a technologist assessing technology built by another team, it is easy to focus on finding issues with the intent of demonstrating your technical expertise rather than providing useful advice. You look for flaws because the system doesn't follow the best practices you know. The team isn't organised the way you would organise it. Their choices don't match what "good" looks like from your own experience.

That is not helpful to the investor.

Every system is built under real constraints: time, money, people, customers and business pressure. A choice that looks wrong from outside can be very pragmatic once you understand the business it serves.

Holding the two ideas together is important.

Understand the context

Understanding why things were built the way they were before we judge them is necessary.

If there are checklists of questions to be asked for due diligence, asking them in context of business scenarios is more useful. It helps us understand why something matters rather than simply checking whether it follows a best practice.

For example, rather than asking – "Can you show us your audit logs?" probing "If someone changes a critical setting by mistake, how would you find out, and how would you know who did it?" will give you more pointers grounded in business context rather than checking conformance to best practices.

Trust the evidence

Being generous about context does not mean taking every answer at face value.

Listen to the claim, probe it, then check it in the code and the data. The answers that sound the most polished get checked the hardest.

In one Tech DD, the team told us their product had been extended to new countries by reusing one shared platform, with local customisations on top. In conversation, it sounded like a well-designed multi-tenant system.

The code told a different story.

There was a separate copy of the system for each country, each with its own changes. A bug found in one country had to be fixed in four other places. The company planned to launch in more countries over the next few years. Each new country meant another copy to maintain, and the team would have to keep growing just to keep up.

The long-term cost of running the platform was going to keep going up with every new country.

In the same Tech DD, the team told us their data and transactions were fully auditable. We could only confirm that, and in parts disprove it, by going through the database structure together with the team.

Conversations tell you what the team believes. Code and data tell you what is true.

What we assess at Sahaj

The five questions we discussed above are what we want to answer for the investor. To get there, we assess eight areas.

We score each area on a scale of 1 to 5. Every score connects back to what we actually saw in the code, the data or our conversations. This keeps the assessment as objective and grounded as possible.

On AI in particular almost every company now says its product is AI-powered.

We look at which models are used, whether the product is a thin layer over an AI provider's API (Anthropic, OpenAI, Google), the quality of the data behind it, and how the models are trained.

The answer changes what the investor is actually buying.

How we do Tech DD at Sahaj

A good Tech DD is not only about what you find. It is also about how you go about it & deliver it.

• Independent

An independent view generally means a view without bias or conflict of interest. Such views are generally trusted more by both the investor and the company being assessed, because they know the recommendations come from a position of independent advice rather than an interest in benefiting from the outcome.

This is a stated position across Sahaj. We don't take follow-on work for companies we have assessed, so the possibility of future work does not influence what we recommend or write in our reports.

• Fast

Two consultants, typically about two weeks, end to end. That covers conversations with the team, probing and checking, writing the report, reviewing the facts with the technology team, and sharing the final report with the investor.

• Specific

Findings point to real parts of the system: specific services, modules, flows and database tables. The investor, and later the team, can see exactly what we mean.

• Prioritised

Recommendations are sorted with an Eisenhower matrix: what is urgent and important for the next three months, what is important but can wait, and what is neither. This provides a clear prioritized roadmap for the technology team to act on.

• Forward-looking

We recommend a product roadmap and a target architecture, with a view of the cost to fix or rebuild.

• Validated Findings

The first draft of the report is shared with the technology team to validate our understanding, facts and observations. The team can challenge any observation they believe is incorrect. Only validated observations, along with scores and recommendations, are shared with the investor in the final report.

In one Tech DD, this process changed our finding. We had concluded that auditing was weak. The team walked us through how audit trails worked for critical transactions and configuration changes, and we corrected our understanding before the final report.

Thus, the aim is not to produce a long list of issues. It is to give the investor a clear view of what is there today, what it means for the business plan, and what needs to happen next.

If you are the one being assessed

If you are a founder or CTO preparing for a Tech DD, here is what we at Sahaj look for in a well-run team:

• Honest answers beat polished ones, building more trust than a perfect story.
• A real technical debt backlog, with the reason for each shortcut.
• Knowledge that doesn't live in one person's head. Documentation and shared ownership.
• Decision-making is not overly dependent on the CTO.
• A roadmap the business recognises and agrees with.
• The ability to show it, not just say it. In the code and in the data.

The system does not need to be perfect. What matters is that the team knows its system well.

To Conclude

The point of a Tech DD isn't to prove that a system has flaws. Every system does, and a good technologist can always find more.

The point is to help an investor understand what they are actually buying, what risks need to be mitigated and what needs to change to support future business growth.

Is the technology an asset or a cost? Can it support the business plan? Can you trust the data? Can the team take the product where the business wants to go? What needs to change, and what will that change cost?

The system worked in the example I started with. It just didn't work the way we were told.

A good Tech DD closes that gap. It separates the story from the evidence, but it also puts the evidence in the context of the business.

That is what gives an investor the clarity to know what they are buying, what they need to invest in, and what they are paying for.