What Technology Due Diligence Should Tell You Before You Invest

Technology Due Diligence Should Tell You What You Are Really Buying

Technology due diligence should tell you far more than whether the software works today. It should tell you what you are actually investing in, where the hidden risks sit, what may need to be fixed and whether the technology can support the business plan you are being asked to believe.

A product can look impressive in a demonstration and still be expensive, fragile or difficult to grow. The development team might be delivering new features while quietly accumulating technical debt. Critical knowledge might sit with one developer. Security controls may exist on paper but not in practice.

A good technology due diligence review gets underneath that surface.

It connects the technology to the investment thesis and asks a much more useful question:

Can this technology realistically support what the business intends to do next?

That is the question I want answered before money changes hands.

Takeaways

What Is Technology Due Diligence?

Technology due diligence is an independent assessment of the technology, people, processes and risks behind a business or investment.

For a software or SaaS company, that usually means looking beyond what the application does. You want to understand how it is built, operated, secured, maintained and developed.

For a business that depends heavily on technology without actually selling software, the questions can be different. You may need to assess critical systems, suppliers, data, integrations, cyber risk and the company’s ability to operate if something fails.

It complements commercial, financial and legal due diligence rather than replacing them.

Commercial due diligence may tell you that a market opportunity exists. Financial due diligence may validate the numbers. Legal due diligence may establish ownership and contractual obligations.

Technology due diligence asks whether the technology can actually support those expectations.

That distinction matters.

Current Australian deal commentary reflects this shift. EY’s 2026 analysis of software M&A highlights scalability, technical debt, security, key-person dependency and integration capability as areas capable of affecting investment value. PwC has also noted that Australian buyers in 2026 are placing greater emphasis on price and deal structure as they assess technology opportunities.

Start With the Investment Thesis, Not the Source Code

One of the easiest mistakes in technical due diligence is starting too low down.

Someone opens the source code, runs a security scanner and starts counting issues.

That may produce an impressive report. It does not necessarily tell an investor what they need to know.

I prefer to start with the business case.

What are you expecting this investment to do?

Perhaps the plan depends on:

• doubling the customer base within two years;
• expanding into new markets;
• integrating the product into another company;
• reducing development costs;
• introducing AI capabilities;
• moving enterprise customers onto the platform;
• acquiring another product and combining them;
• replacing the founder with a broader leadership team; or
• reaching a future acquisition or exit.

Those assumptions give the technology review context.

If the business plan expects customer numbers to triple, scalability matters.

If enterprise customers are the target, security, support, auditability and compliance become more important.

If the company will be absorbed into another group, APIs, data structures, identity management and integration constraints deserve closer attention.

Without that context, technical due diligence risks becoming a long list of observations without telling you which ones matter.

This is why my approach to Technology Due Diligence starts with the business objective and works backwards into the technology.

Can the Software Support the Growth Story?

Growth forecasts deserve technical questions.

A system supporting 10,000 users is not automatically capable of supporting 100,000. A development process that works with five engineers may struggle badly with twenty. A database that performs well today may become the bottleneck when transaction volumes increase.

You do not necessarily need sophisticated modelling to identify the risk.

Look at areas such as:

• architecture and major components;
• infrastructure capacity and configuration;
• database design;
• performance monitoring;
• availability and uptime;
• deployment processes;
• backup and disaster recovery;
• known bottlenecks;
• load or performance testing;
• third-party service dependencies; and
• previous incidents caused by growth or capacity.

The goal is not to predict every problem.

It is to work out whether the company’s growth assumptions are technically believable and what investment may be required to support them.

That can materially change your understanding of the deal.

A company may say, “The platform is ready to scale.“

The diligence question is:

What evidence supports that statement?

That one question tends to be surprisingly productive.

Technical Debt Is Really Future Spending

Technical debt is often misunderstood as untidy code.

It is broader than that.

Technical debt is work that has effectively been deferred. Sometimes that is deliberate and sensible. Early-stage companies make compromises because speed matters and money is limited.

The problem is not that technical debt exists. Almost every established software product has some.

The important questions are:

How much is there, where is it, why does it exist and will it interfere with the investment plan?

For example, a platform may contain:

• an ageing framework that is difficult to support;
• unsupported software dependencies;
• duplicated functionality;
• limited automated testing;
• manual deployments;
• undocumented integrations;
• database structures that restrict new development;
• temporary fixes that became permanent;
• old modules nobody wants to touch; or
• a backlog filled with maintenance work continually pushed aside for new features.

These issues eventually consume time and money.

Suppose your investment case assumes the development team will spend the next 18 months building features that drive revenue. Due diligence then discovers that the platform needs six months of architectural and infrastructure work before those features can be delivered safely.

The investment has not necessarily become bad.

But the economics have changed.

That is information you want before you invest, not six months afterwards.

Who Actually Understands the Technology?

This is one of my favourite due diligence questions because it exposes risk very quickly.

Ask:

If one person disappeared tomorrow, what would stop working?

The answer might be the founder.

It might be the CTO.

It may be an internal developer, a freelance contractor or someone working for an external development agency.

I have seen businesses where critical technology knowledge effectively lives inside one person’s head. They know how deployments work, where the strange database problem lives, why a particular integration periodically fails and which bit of the application nobody should change on a Friday afternoon.

That is key-person technology risk.

Documentation helps, but the real question is whether the organisation can continue operating and developing the product without that individual.

I would look at:

• ownership of critical systems;
• documentation;
• access to source code and infrastructure;
• password and credential management;
• development responsibilities;
• succession or handover arrangements;
• use of contractors;
• dependency on development agencies;
• staff turnover;
• recruitment difficulty; and
• whether specialised or obsolete technologies restrict the hiring pool.

This is where my “people before technology” approach becomes particularly important.

A technically clever system supported by a fragile team structure is still a fragile system.

For businesses already concerned about leadership capability or concentration of responsibility, a separate Technology Leadership review can also help establish whether the organisation has the right leadership structure for the next stage.

Does the Company Really Own What You Are Buying?

An investor should never simply assume that a company owns all of its technology.

You need to establish what was created internally, what came from contractors, what is licensed and what depends on third-party intellectual property.

Questions can include:

• Who wrote the original software?
• Were employees or contractors responsible?
• Were intellectual property rights formally assigned?
• Is open-source software being used?
• What licences apply to those components?
• Does the product depend on commercial libraries or APIs?
• Are licences transferable following an acquisition?
• Who owns domains, repositories and cloud accounts?
• Are software assets registered under the company or an individual’s account?
• Does anyone outside the company retain privileged access?

Legal advisers should assess the contractual and legal position.

Technology due diligence helps identify where they need to look.

This distinction matters because a source-code repository full of software is not proof that the company has unrestricted rights to everything inside it.

Cybersecurity Due Diligence Needs Evidence

A questionnaire asking “Do you take cybersecurity seriously?” is unlikely to uncover much.

Almost everyone answers yes.

Technology due diligence needs to move from statements to evidence.

I want to understand areas such as:

• identity and access management;
• multi-factor authentication;
• privileged access;
• software patching;
• backups;
• security monitoring;
• incident management;
• vulnerability management;
• secure development practices;
• data encryption;
• third-party access;
• employee offboarding; and
• disaster recovery.

Australian organisations can use the Australian Signals Directorate’s Essential Eight as one useful reference point for common security controls.

For organisations needing a broader framework, the NIST Cybersecurity Framework and ISO/IEC 27001 provide established approaches to cybersecurity and information security management.

That does not mean every small software company needs ISO 27001 certification.

The level of control should make sense for the company, the information it holds, its customers and the risk involved.

An early-stage B2B application processing limited non-sensitive data has a different risk profile from software handling health information, financial transactions or government data.

The due diligence needs to understand that context.

Look at What Has Already Gone Wrong

Past incidents can reveal more than policy documents.

Ask about:

• security incidents;
• major outages;
• lost data;
• failed releases;
• customer-impacting defects;
• performance problems;
• privacy incidents;
• emergency infrastructure changes; and
• periods when the development team could not release software.

Then ask what changed afterwards.

This tells you something important about organisational maturity.

Things go wrong in technology. An organisation claiming nothing has ever failed may have extraordinarily good systems, or poor visibility.

I am much more interested in whether the organisation detects problems, communicates clearly, learns from them and improves.

That tells you far more about future risk.

Can the Development Team Reliably Deliver?

A strong product can still be a poor investment if changing it takes forever.

I would look at how work moves from an idea to production.

That includes:

• planning and prioritisation;
• product ownership;
• development practices;
• code review;
• automated testing;
• release processes;
• deployment frequency;
• defect rates;
• production support;
• technical backlog management; and
• how progress is communicated to leadership.

Tools do not prove maturity.

A company using Jira, automated deployment tools and cloud infrastructure can still have chaotic delivery.

I care more about whether people understand what they are building, whether leaders can see progress and whether the organisation can repeatedly turn investment into working software.

Where delivery itself is the concern, Project Delivery should look beyond project status reports and examine what is actually preventing work from reaching customers.

Does the Roadmap Match Reality?

Roadmaps deserve healthy scepticism during technology due diligence.

A beautifully presented roadmap can show what management would like to build. It does not prove that the organisation has the capacity to deliver it.

Compare the roadmap against:

• historical delivery;
• team size;
• current commitments;
• maintenance workload;
• technical debt;
• dependencies;
• recruitment plans; and
• infrastructure work.

Imagine a company normally completes two substantial product changes per quarter.

The investment presentation suddenly assumes ten major capabilities will appear during the next twelve months without increasing engineering capacity or changing how the team works.

That deserves questions.

Forecast revenue based on features that cannot realistically be delivered is not just a technology risk. It is an investment risk.

What About AI?

AI has made this question much more relevant.

An investor may now hear that AI will reduce development costs, differentiate the product or create an entirely new revenue stream.

Perhaps it will.

The diligence process should separate what exists from what is planned.

Ask:

• What AI capability is in production now?
• Which models or providers does it rely on?
• What data does it use?
• Does the company have the right to use that data?
• How is output quality measured?
• What happens when the underlying model changes?
• What does usage cost?
• What happens to margins as adoption grows?
• What information is sent to external AI providers?
• Are there human review or control mechanisms where needed?

EY’s 2026 Australian analysis specifically identifies AI, proprietary data and technical defensibility as increasingly important considerations for software investors.

“AI-powered” should therefore start a conversation during due diligence, not end one.

Turn Technology Findings Into Investment Decisions

A technology due diligence report should not dump fifty technical findings on an investor and leave them to translate the consequences.

Each material issue should answer four questions:

Question	What You Need to Know
What did we find?	A clear description without unnecessary jargon
Why does it matter?	The business, operational or financial consequence
How serious is it?	Probability, impact and urgency
What should happen next?	Remediation, further investigation or deal action

I also find it useful to group findings into four decision categories.

1. Deal Breakers

Problems that fundamentally challenge the investment thesis.

Examples could include disputed ownership of essential technology, security exposure that cannot reasonably be accepted, or a platform incapable of supporting the planned business model.

2. Deal Conditions

Problems that may be manageable but should be addressed before completion or reflected in contracts, warranties or other protections.

3. Post-Investment Priorities

Issues that do not prevent the transaction but need budget, ownership and a timetable after completion.

4. Opportunities

Due diligence should not only look for bad news.

You may discover opportunities to reduce cloud spending, improve delivery, simplify systems, strengthen the team or retire unnecessary technology.

That can contribute directly to the investment case.

A Practical Technology Due Diligence Checklist

For most technology-dependent investments, I would expect the review to consider the following areas.

Business and Technology Alignment

• Investment thesis
• Growth plans
• Product strategy
• Technology roadmap
• Major technology constraints

Architecture and Infrastructure

• Application architecture
• Hosting and cloud environment
• Databases
• Integration architecture
• Reliability and performance
• Backup and disaster recovery

Software and Technical Debt

• Codebase structure
• Frameworks and dependencies
• Automated testing
• Maintainability
• Known technical debt
• Unsupported technology

Cybersecurity and Data

• Authentication and access
• Security controls
• Vulnerability management
• Data handling
• Incident history
• Third-party exposure

People

• Leadership
• Team capability
• Key-person risk
• Contractors
• Recruitment
• Knowledge sharing

Software Delivery

• Development process
• Releases
• Testing
• DevOps
• Quality
• Delivery predictability

Intellectual Property and Suppliers

• Source-code ownership
• Contractor IP
• Open-source dependencies
• Software licences
• Major vendors
• Cloud and SaaS dependencies

Commercial Impact

• Future technology spending
• Remediation requirements
• Integration costs
• Development capacity
• Potential technology savings

This is not a box-ticking exercise.

The scope should reflect why you are investing.

A $2 million acquisition of a small service business with standard SaaS systems requires a different level of investigation from a $50 million acquisition where proprietary software represents most of the company’s value.

Red Flags I Would Want Explained Before Investing

A single red flag does not automatically kill an investment.

Patterns matter.

I would investigate further if I found things such as:

• nobody can clearly explain the architecture;
• only one person can deploy the application;
• cloud infrastructure sits in a founder’s personal account;
• the company cannot produce basic system documentation;
• recurring serious production incidents are treated as normal;
• development estimates consistently bear little resemblance to delivery;
• backups exist but have never been tested;
• former contractors still have system access;
• important technology is no longer supported;
• technical debt is acknowledged but never scheduled;
• the roadmap assumes far more work than the team has historically delivered;
• security scans exist but findings are repeatedly ignored;
• major intellectual property was written by contractors without clear assignment;
• management cannot explain development spending;
• one supplier effectively controls the company’s ability to operate; or
• the answer to reasonable questions repeatedly becomes “ask Dave“.

Dave may be excellent.

Your investment should probably not depend entirely on Dave.

What Should Happen After the Technology Due Diligence?

The report should become part of your decision-making process, not disappear into the deal folder.

Material findings may influence:

• valuation;
• deal structure;
• warranties;
• conditions before completion;
• investment milestones;
• technology budget;
• management appointments;
• integration planning;
• cybersecurity priorities;
• product planning; and
• the first 100 days after investment.

Some findings may justify walking away.

Others may actually make the investment more attractive because you now understand a solvable problem that previous owners have not addressed.

The point is visibility.

You can make a conscious investment decision when you know the risk. Hidden technology problems are much harder to price.

If the investment is part of a broader business strategy, Technology Strategy can then turn the diligence findings into a practical roadmap rather than allowing the report to become another PDF nobody opens again.

Frequently Asked Questions

What is technology due diligence?

Technology due diligence is an independent review of the technology, systems, software, people, processes and risks behind a business or investment. Its purpose is to establish whether the technology supports the investment thesis and identify issues that could affect value, cost, growth or continuity.

What should technology due diligence include?

The scope normally considers architecture, infrastructure, software quality, technical debt, cybersecurity, data, software delivery, technology leadership, key-person risk, intellectual property, suppliers and the future technology roadmap. The exact scope should reflect the investment and the role technology plays in the business.

When should technology due diligence be performed?

Ideally, it happens early enough for the findings to influence the investment decision. Leaving it until the deal is effectively agreed reduces your options if the review identifies material risk.

Is technology due diligence only necessary when buying a software company?

No. A business does not have to sell software to be heavily dependent on technology. Customer systems, operational platforms, integrations, data, cloud services and key suppliers can all create material investment risk.

Does technical due diligence include reviewing source code?

It can, where appropriate, but source-code review is only one part of the picture. Architecture, security, infrastructure, people, development practices, ownership, suppliers and commercial plans can be just as important.

Can technology due diligence affect the purchase price?

Yes. A review may identify investment required immediately after acquisition, technical limitations affecting forecasts, unrecognised risks or integration costs. Those findings can inform valuation, negotiation, warranties, conditions or the post-investment budget.

Technology Due Diligence Is Really About Investment Confidence

I have spent enough time around software projects and technology teams to know that every system has imperfections.

The goal is not to find perfect technology.

It is to understand what you are buying.

You should know whether the platform can grow, how much work has been deferred, where knowledge sits, whether security controls are credible, whether development plans are realistic and how much additional investment may be required.

That gives you something far more useful than a green tick beside “technology”.

It gives you informed confidence.