Technical Due Diligence Services

Technical due diligence is an independent assessment of a company's software, infrastructure and engineering practice, produced so an investor, acquirer or board can price technical risk before a deal closes. SWARECO carries out that assessment and delivers a written verdict you can act on, not a scorecard.

The questions that decide a deal are rarely the ones on a generic checklist. Will this architecture survive the growth the model assumes? How much of the roadmap is rewrite work in disguise? Is the team's velocity a property of the team, or of one person who has not taken a holiday in two years? We answer those, with the evidence attached.

Engagements start with the investment thesis, not the codebase. What a buyer intends to do with the asset determines which risks matter, so we scope against that before requesting any access.

From there: read-only repository and infrastructure access, structured interviews with the engineering leads, static and dependency analysis, and a review of the deployment and incident history. How a system has failed before is the most reliable guide to where it is fragile now.

The output is a written report with findings ranked by cost to fix and consequence of not fixing, plus a verbal readout for the deal team. Turnaround is typically one to three weeks depending on codebase size and how many systems are in scope. Where the deal timeline is tighter, we scope a reduced assessment and state plainly what it does not cover.

We evaluate four things in depth — the code, the infrastructure, the security posture and the engineering practice — and we weight them against what the buyer intends to do with the asset. A minority growth investment and a full acquisition ask different questions of the same system, and a report that ignores that distinction is a checklist rather than a judgement.

How we evaluate the code

We read the repository directly rather than relying on a questionnaire. Static analysis and dependency scanning establish the mechanical facts: unsupported runtimes, known vulnerabilities, packages nobody has updated in three years, and how much of the revenue-critical path the test suite actually covers. Then engineers read the parts that carry the business logic, because the expensive problems are structural and no scanner reports them. SWARECO works in Ruby on Rails, React, React Native, TypeScript, PostgreSQL, Redis, Docker, AWS and Heroku, so for systems on that technology the benchmark for normal comes from platforms we operate rather than from a maturity framework.

The AI questions now on every software deal

Two questions about artificial intelligence appear in most diligence engagements, and they are different from each other. The first is provenance: how much of this codebase was generated, whether it was reviewed to the same standard as hand-written code, and whether the licence position of the generated code is understood. Generated code is not a defect in itself, but a codebase where nobody can say which parts were generated and which were reviewed is a maintenance risk that will not show up in the metrics.

The second is capability. Where a company’s valuation rests on an AI feature, diligence has to establish what is actually running — a fine-tuned model, a retrieval system over a proprietary dataset, or a prompt against a third-party API that a competitor could reproduce in a fortnight. The defensibility of each is wildly different, and only one of them is a moat. We say which one it is, and what it would cost a competitor to match.

Concentration risk, which is usually the real finding

The most common material finding in a software business is not architectural. It is that one person holds the knowledge required to keep the system running, and the deal model assumes that person stays. We evaluate who can deploy, who understands the data model, who gets called at 3am, and what has been written down. Where the answer is one name, the report says so in those terms, because the mitigation is a retention condition rather than an engineering task.

What the report will not tell you

Diligence establishes the technical facts and prices the risk. It does not tell you whether to do the deal, and it cannot certify the absence of a vulnerability — no assessment can, and a report claiming otherwise is worth less than one that states its limits. We record what was in scope, what was not, and what we would want to look at with more time, so the deal team knows exactly which risks were assessed and which were merely accepted.