Technical Due Diligence · Maturity Assessment
I'll tell you what the technology can really do.
Acquisition, investment or major modernization: I check code, pipelines and infrastructure right in the repositories, talk to the developers — and tell you what holds and what doesn't. Every finding with a location.
2 weeks
5 questions
12+
ISO 25010
What gets checked
46 capabilities along the delivery phases, each rated meets, deviates, delegated or n/a. Delegated doesn't mean out of scope; then I check the interface to the operator. The check criteria behind it stay my tool.
The tooling run
Where the target allows it, my tooling runs in its pipeline and supplies the evidence behind the rating. An excerpt, values fictitious:
What you get
Four pages from the report template: contents, executive summary and roadmap from the high-level report, one finding from the deep-dive report. Values fictitious — click through or let it run.
Every finding has a location: file and line, commit, tool output, document or dated interview. Anyone who disputes a finding can check it.
Four occasions, one process
Two examples: a banking-as-a-service platform ahead of a funding round and the 6R analysis with a make-vs-buy business case for an energy software provider.
Know what you're taking over before you buy
The target's architecture, code, team and roadmap. What is solid, what is risk, what does modernization cost? Report in two to four weeks.
Pitch versus reality
Does the foundation scale, can the team carry the vision? Post-investment support on request.
Find it before the buyer does
The same assessment, commissioned by the target: what a buyer would find, you find first and fix before the data room opens.
Where does your platform stand?
Before a modernization, migration or growth push. Result: a 6R classification and a make-vs-buy business case.
Engagement models
Red Flag Review
Is there a reason to stop or renegotiate?
- ✓Deal-breaker categories only, no maturity scores
- ✓Key-person risk from the Git history
- ✓Licences, secrets, runtimes past end of support
- ✓Outcome: full DD yes or no, and where to focus it
For: acquirers and investors, before the full DD starts
Full Tech DD
The complete assessment along all five questions.
- ✓Team, security, IP and the regulation of your industry
- ✓Every repository surveyed, deep dive where it matters
- ✓Interviews with the team and key people
- ✓Findings in deal language for the board and the deal team
- ✓Implementation roadmap with effort ranges
For: M&A, PE investments, larger targets
Investment Check
The focused assessment, before capital flows.
- ✓Architecture, code and process review
- ✓Team assessment — can they execute the vision?
- ✓AI claims checked against reality
- ✓Red flags, five questions, rough roadmap
For: VC/angel investments and smaller targets
Maturity Assessment
Maturity per dimension, with a roadmap instead of a list of findings.
- ✓Code and architecture quality based on ISO 25010
- ✓6R classification of the landscape
- ✓Make-vs-buy business case
- ✓Roadmap with effort ranges, pilot first
For: your own platform before major decisions
Happy to sign an NDA before the first call. For assessments beyond technology and for vendor DD with reliance, I partner with consulting firms and deliver the technical part.
How an assessment runs
Three phases, two documents
At the end stand the high-level report for the board and the deal team and the deep-dive report for the CTO and engineering, with the same findings at different depth.
Access & overview
In the room: the client, the target's management
We clarify what gets assessed and what matters most to you. In the first interviews, the team shows me where code, pipelines and infrastructure live.
- ▸Set scope, questions and exclusions
- ▸Request list for the data room
- ▸Overview of repositories, pipelines and infrastructure
- ▸Clarify access and tooling
Outcome: A clarified scope and clarified access.
Deep-dive
In the room: the target's team and key people
Documents describe the target state, the code the actual state. Interviews clarify the gaps.
- ▸Code analysis down to the architecture, tool-assisted where allowed
- ▸Git history: who knows which code?
- ▸Pipelines, infrastructure code and operations
- ▸Interviews on findings and contradictions
Outcome: Findings with location and evidence level.
Verdict & report
In the room: the deal team or management
Findings get weighed: what is deal-relevant, what is ordinary technical debt, what would a possible fix cost?
- ▸Red flags collected up front, never averaged away
- ▸Five questions for the board, detail for engineering
- ▸Roadmap with an effort range per package, pilot first
- ▸Walkthrough with the deal team or management
Outcome: The finished report, walked through rather than just sent.
Why my assessment comes out different
From someone who builds
12+ years of platform and architecture work in banking, energy and industry. I know how technical debt is born and what a fix would cost. That's why every report ends with a roadmap and effort ranges.
Deep code review
I do the analysis myself. Where the target allows it, also tool-assisted in its pipeline, read-only. Interviews confirm; they replace no finding.
AI substance as a dimension
How solid are the AI claims? Model dependencies, data flows, running costs, GDPR and EU AI Act risks. Assessed by someone who builds production AI systems himself.
Findings in deal language
Every finding carries a severity, from deal-breaker through price and closing condition to observation, plus an evidence level. What I only know from interviews is marked as an indication, never stated as fact.
From the field
- Published on
A Smart Start for Startups
Asked up front
Do you need access to the code?+
Read access, yes, as far as it goes: repositories, pipeline definitions, infrastructure code. What I was allowed to see determines how firmly I judge. A finding from the code is marked as evidenced in the report, one from an interview as an indication.
What runs in the pipeline?+
Only if you want it. On request, my tooling ships as a signed container image with an SBOM, runs inside the target's CI/CD pipeline, read-only via an access token scoped to read_api, with no write rights, and stores the findings as a pipeline artifact. The security team can review the image first. Without that approval, I check manually, against the same check items.
And if there is no code access at all?+
Then interviews, code shown on screen and requested exports such as pipeline definitions and scan reports carry the assessment. The affected findings are marked as indications, and the missing access is stated up front as a scope limit.
Do you use AI?+
My tooling uses no AI. Whether I use AI afterwards for analysis, code review and writing is up to your contract, in stages. Without approval, the report is written without AI.
Do you check compliance too?+
I fully check the regulation your engagement or industry requires, for example DORA for suppliers to banks. What I check is technical implementation and evidence. Legal interpretation and contracts stay with the legal DD; the report names the interface.
Does the target get your check catalogue?+
Up front, it gets a request list for the data room and the interview agenda. On buy-side and investor assessments, I don't hand out the full catalogue. Anyone who knows every question in advance polishes exactly those spots.
Next step
Let's talk about your target
30 minutes: you sketch the case — target, occasion, timeline. I tell you what an assessment can deliver, how long it takes and what it costs.