See what the platform can do. Decide whether it fits your plans.

Web platform technical due diligence

Before an investment, acquisition, or supplier decision, we can help you to establish what the software you are considering can do and what it would take to maintain or scale it further.

Here, we look closely at the web platform and its engineering evidence. We don’t provide wider financial or legal due diligence, intellectual-property assurance, or a specialist cyber-security assessment.

For investors, acquirers, CTOs, programme sponsors, and legal advisers seeking to inform investment, acquisition, or supplier decisions.

When platform due diligence helps

  • An investment depends on the technology

    You want to know whether the software can support the plans behind an investment and what further engineering work those plans would require.

  • You are taking on an existing platform

    You need to understand what you would inherit: how the software is maintained, what it depends on, and what another team would need to support it.

  • You need to assess a supplier’s work

    Before selecting a supplier or accepting a handover, you want to check that the working software supports the capabilities being promised.

A real engagement

Examining a software business before acquisition

A prospective buyer asked John to review the inner workings of a small software business as part of its acquisition due diligence. The examination focused on the implementation and the engineering work involved in maintaining it.

Following a fix through the release process

The software had begun as a shared platform serving multiple clients from one codebase. Over time, it had fragmented into separately maintained versions, with different features for each client.

The release process made the consequences clear. Even a small fix took a full day of engineering time to apply manually across the different versions. Each release carried the risk of missing a version or introducing another inconsistency, alongside the recurring work of keeping those variants up to date.

Making the maintenance burden clear

The review established that the buyer would be inheriting a collection of separately maintained variants, with a substantial demand on engineering time for routine changes. That gave the buyer a clearer understanding of the platform’s maintenance burden when considering the proposed acquisition.

What we examine

We agree the scope, depth, and access with you before work begins.

  1. What the platform can do

    We examine the implementation behind the features you are being shown and test the stated capabilities. This helps establish whether the platform can do what you need today and where it would need further work.

  2. Code quality and maintainability

    We look at how the code is organised and tested, how the repositories are maintained, and the architecture behind them. These choices affect how much work a team would need to do to fix problems or develop the platform further, including whether a routine change is straightforward or requires substantial engineering effort.

  3. Dependencies and operational constraints

    A platform may rely on a content management system, external integrations, or particular deployment arrangements. We examine those dependencies to understand what is needed to keep it running and where they could constrain changes.

  4. Remaining work and technical risks

    We work through your plans with the people making the decision and speak with the delivery team about what has been completed and what is still to do. Checking this against the software helps us identify unfinished features, dependencies, and other technical work that could affect your plans.

How we work with you

  1. Start with your plans for the software

    We start with what you want to do with the platform, the decisions already made about it, and the questions you need answered before proceeding. Together, we agree what we can usefully examine within your deadline and the access available.

  2. Examine it with the delivery team

    Alongside inspecting the architecture, repositories, and working software, we speak with the engineers, designers, and product team about how it was built and how it is maintained.

  3. Check the fit with your plans

    We compare the capabilities being described with what the software can support in practice. Looking at its strengths and limitations in the context of your plans helps establish where it is a good fit and where further development would be needed.

  4. Discuss the work you would be taking on

    We explain the likely maintenance burden and the engineering work your plans would involve. You can work through the findings with us and identify questions that need answering before you commit.

Your report and briefing

An assessment of the platform

Your written report explains what the platform can do, where its limitations lie, and the engineering work involved in maintaining or developing it. We set out the evidence behind our findings and what it means for the investment, acquisition, or supplier decision you are considering.

Questions to resolve before you commit

Where a finding needs more investigation, we set out the questions to take back to the owner, supplier, or other advisers. That includes any access or specialist input needed to reach a conclusion.

A conversation about the findings

Your sponsor briefing is a conversation with John about the report. There is time to question the findings and discuss what they mean for your plans. We can also agree briefings for the people who need to act on them, from engineers and suppliers to senior leadership and the C-suite.

Practical questions

Is this complete due diligence on a business?

No. We examine the agreed web platform and its engineering evidence. We don’t provide financial, legal, intellectual-property, or specialist cyber-security assurance. Our findings can inform a wider due-diligence process led by your other advisers.

What if access to the platform is restricted?

We discuss the access available before agreeing the review. If we cannot inspect a repository, use an environment, or see supporting material, we explain which questions remain unanswered. We don’t treat a capability as verified when the evidence needed to check it is unavailable.

Can the work support an investment or acquisition deadline?

The time needed depends on the platform’s complexity, the questions you need answered, and how readily we can access the software, supporting material, and people involved. We discuss your deadline and our availability before agreeing the scope, so you know what we can realistically examine in the time available.

How are scope and fees agreed?

We start by discussing what you need to decide, your deadline, and the platform involved. We can then establish whether the work is a good fit and confirm our availability. Before investigation begins, we agree the scope, fees, and access with you, including who needs to be involved and the arrangements for your written report and sponsor briefing.

Is the review automated?

No. John conducts the core investigation and is responsible for the judgement and recommendation. AI-assisted analysis is only used with your approval and suitable security controls; it does not replace his examination of the evidence.

Who does John interview?

John speaks with the people funding and sponsoring the work, business stakeholders, and those designing, building, and delivering it. We agree who needs to take part and the access required. Comparing their experience with the software and delivery evidence helps us understand expectations, constraints, and what needs attention, without apportioning blame.

John Kavanagh, founder of Kavanagh Digital

About Kavanagh Digital

A builder’s view of the platform.

John Kavanagh, founder of Kavanagh Digital, brings more than two decades of experience in hands-on development, front-end architecture, and engineering leadership. He leads every review and takes responsibility for its conclusions.

His wider work across content platforms, migrations, performance, and accessibility informs the questions behind a due-diligence review. John considers what a platform can do today alongside the engineering effort and knowledge needed to maintain or extend it.

Discuss platform due diligence

What are you considering?

Tell us about the software, what you want to do with it, and when you need to decide. We’ll discuss the questions a review could answer and the access needed to get started.

Email us