What I do

Read this if

• you are about to invest and the technical component has not been tested by someone independent.
• you have signed an LOI and need to know what you are inheriting.
• you own an asset and engineering has become unpredictable.

My principles

• Severity is rated against your objective, not against generic best practice. A monolith that cannot scale 10x is critical if you are funding growth but irrelevant if you are buying the team.
• Findings are validated against evidence and include mitigation options. This makes the result actionable in the real world.
• Limits in scope and confidence are stated upfront and fixed in writing. Knowing upfront what you get and won't get is key to a healthy relationship.
• Clear answers with transparent reasoning. Everything else is just another opinion.

What I examine

I can cover the following domains. Depending on your objective and time constraints, we pick the relevant domains and necessary depth. See Technical assessment and due diligence → for more details.

• Architecture and scalability: Does it fit the current stage and survive the next one?
  Example red flag: Built single-tenant but sold enterprise. Multi-tenancy is a rewrite, not a feature.
• Code quality and debt: Churn, AI slop, complexity, test coverage, sanity.
  Example red flag: Unit tests everywhere, but not testing actual user flow end to end.
• Delivery: Feature delivery, cadence, git hygiene, CI/CD.
  Example red flag: Deployments require named individual and downtime.
• Team: Key-Person risk, work concentration, tribal knowledge
  Example red flag: 70% of all code is written by a single individual.
• Security: Dependency exposure, authentication, environments, secret handling, tenant isolation, development practice.
  Example red flag: Production credentials in git history, they were not rotated properly.
• IP and Licensing: Chain of usage rights, contractor assignments, OSS license compatibility, AI generated code provenance.
  Example red flag: License breaches due to uncontrolled use of third party libraries and dependency chains.
• Cost to recreate: Effort to rebuild code and content. Input for valuation, not a valuation itself.
  Example red flag: Cost to recreate is 15% of the asking price. You are paying for the name or customers, not the code.
• Infrastructure and cost: Hosting spend, vendor lock-in, scaling headroom.
  Example red flag: Overuse of hyperscaler features for what could be a single VPS.
• Regulatory and AI exposure: Relevant baselines like GDPR, AI Act.
  Example red flag: Claimed compliance broken by backups and uncontrolled production environment access.

How an engagement runs: 1 week Engineering Assessment

The 2- and 4-week Tech and IP Due Diligence follows the same method with deeper coverage and a formal presentation.

Timeline

You get the report by end of the week.

• Day 1: Onsite, Kickoff, Tour, Interviews
• Day 2: Onsite, Interviews
• Day 3: Analysis, questions and clarifying interviews
• Day 4: Analysis complete, draft validation round with target team
• Day 5: Report delivered, findings and action plan presented

Deliverables

• State of engineering report, 5-10 Pages. Half-page management summary, scope and findings rated by severity and what that means for your objective.
• Top 5 risks: Evidence-backed top 5 risks according to target and focus, including mitigation options, cost, and consequences
• 90 day action plan: Realistic high-level action plan which takes ongoing objectives into account. Support during execution is a separate mandate. See Interim & fractional CTO → for details.

Requirements

Under ideal conditions, the assessment is done with access to the most important functions of the target. In reality, access friction is a signal in itself and stated in the report as well as noted in the confidence ratings of findings. A target that can't produce contractor agreements or grant read access in a week is telling you something.

• Read access to repository and adjacent tools like planning, CI/CD, documentation, test suite. The main tools of the engineering teams provide data and metadata to team structure and processes. I use that to assess key-person risk, churn, and delivery quality.
• Access to security functions and their systems. Handling of secrets, operational security and how integrated security practices are into general development are major indicators of the security posture and therefore in overall health.
• Access to live infrastructure and cost management. Required to evaluate hosting spend, assess possible vendor lock-in as well as scaling headroom. It also shows possible deviations from stated processes in real life.
• Contract documentation of all former or currently involved parties including NDA, IP rights, and usage rights as well as licenses. These are necessary to flag gaps and possible risks in the chain of usage rights to avoid unpleasant surprises or transferability issues.
• Public Materials like the website, pitch decks, and product marketing. Checked against what the product actually does. Overstated AI, security or GDPR claims are a liability. Public claims are often written by someone who never asked engineering.
• Time from your people. Kickoff, 4 to 6 interviews with key personnel, one validation round, one presentation slot. Interviews are where I find the things the code doesn't show. This is usually the hardest thing to schedule.

Scope and limits

How the scope is set

The scope is set per engagement and follows your objective. Factors like the size of the codebase, number of services, the depth of each domain you want covered, the relevant interviewees and the time frame we have drive the final proposal. You get the scope and depth of each domain finalized in writing and part of the proposal before you sign.

Exclusions

• No valuation. Cost to recreate is an effort estimate. It can be used as input for your valuation model.
• No legal opinion or counseling. I collect evidence based on provided information and trace chains of IP and usage rights. Based on that I flag gaps. Whether the gaps are enforceable is your counsel's call.
• No certification audit. I provide answers, not certificates. If you need a certification like ISO 27001 or SOC 2, I help source and manage a certified provider and work on mitigations to close their findings.
• No penetration testing. I assess security posture and practice to assess risk, not individual technical vulnerabilities. If you need a pentest, I help source and manage a certified provider and fold their findings into the report.
• No commercial or financial diligence. I don't do market research, revenue analysis or contract audits. Not my area of expertise.
• No remediation during engagement. Fixing findings is a different mandate and we can talk about that after delivery.

Confidence limits

All work is based on the information that is available to me, additional assumptions are marked as such. Each finding includes the evidence backing it, but each assessment is sample-based and time-boxed, not exhaustive.

When a target's core sits outside my areas of expertise, we discuss that upfront. If necessary, I will help you source and vet a specialist and integrate their findings. You will still get one report and one person accountable for it.

Get in touch

Not sure which engagement fits? 30 minutes, no charge. I will tell you what I would scope, which domains matter for your situation, and give you a rough range it lands in.

Book a call →

Yes or no within 24 hours.