The technical side
of your decision.
Technical due diligence before the investment and development capacity for the portfolio company after it. You see, in writing, what the code, the architecture and the team actually look like.
Every finding comes with evidence, unsoftened.
Before the decision
and after it.
- Venture capital and angel investorsYou want an independent view of the technical reality behind the product.
- Private equity fundsTechnical risk before the acquisition and integration cost after it drive your decision.
- Portfolio companiesThe investment is in, but development capacity is not keeping up with the product.
- Corporate acquirersYou are examining the handover, dependencies and sustainability of software you are about to take on.
Not a report,
decision support.
Code and architecture
Code quality, where the architecture stops scaling, test coverage and release discipline; which decision will cost later.
Technical debt and roadmap
How large the inherited debt is, how much of it is urgent and in what order it should be paid down.
Security and compliance
Authentication, authorization, data boundaries, secret management and open ends on the GDPR/KVKK side.
Licence and dependency risk
Open-source licence compliance, vendor lock-in and knowledge that depends on a single person.
Infrastructure and cost
How cloud cost behaves as usage grows, where the waste is and where capacity runs out.
Team and process
Real capacity of the team, how knowledge is spread, deployment frequency and incident-handling maturity.
From access
to findings.
- 01
Scope and access
What will be examined and which access is granted; NDA and, where used, the data room setup.
- 02
Examination
Code, infrastructure, process records and interviews with the team; findings are collected with evidence.
- 03
Findings and priority
Every finding is sorted as “affects the investment decision / handle in the first year / noted”.
- 04
After the investment
If you want it, the same team continues in the portfolio company as development capacity, hiring support or interim technical leadership.
The finding is written
as it is.
- Independent assessmentWe do not soften findings. We write what we saw, with the evidence; the decision is yours.
- ConfidentialityNothing seen during the review is shared with another client. If there is a conflict of interest we say so before starting.
- Evidence-basedEvery finding points to a file, a measurement or a record — never to a hunch.
- No obligation to continueYou are not obliged to continue with the team that did the review; the report stands on its own.
Let’s talk about what
moves the decision.
The scope is narrowed to the questions that actually affect your decision. Looking in the right place beats looking everywhere.
- 01
What worries you most about this investment?
- 02
Which access can be granted: code, infrastructure, team?
- 03
When is the decision date and who receives the report?
- 04
Is post-investment development support on the table?
Before we start.
How long does a review take?+
It depends on scope and the access granted. A single-product team and a multi-system estate are not reviewed in the same time; we narrow the scope and set the schedule together in the first call.
Can you review without code access?+
Only partly. Architecture, infrastructure and process produce meaningful findings, but code quality and technical debt need the source. We state clearly in the report what could not be assessed.
Who owns the report?+
You do. Whether to share it is your decision; we do not share it with the target company.
Do you work with a competing portfolio company?+
We disclose any possible conflict of interest before starting. If needed we decline the work — trust is worth more than one engagement.
Can you also build after the investment?+
Yes, if you want that. But the review is done for the decision, not to win the build; not continuing with us does not change what the report says.
