Technical due diligence for technology startups
Independent technical review for investors, founders, boards, and acquirers looking at a technical startup. I look at the code, architecture, infrastructure, team, and technical risk before a decision gets expensive.
When to bring me in
- Before an investment in a software, infrastructure, SaaS, or technical B2B company.
- When the product works, but the technical risk is unclear.
- When the founding team needs an outside technical read before a round.
- When a board or acquirer needs a plain-English view of what is real, risky, or missing.
- When the diligence question is not only "does the code compile?" but "can this company scale?"
What I look at
- Architecture, scalability, and maintainability.
- Codebase quality, technical debt, and delivery risk.
- Infrastructure, cloud, Kubernetes, DNS, observability, and operational maturity.
- Engineering process, team structure, hiring gaps, and leadership risk.
- Security posture and compliance readiness when they affect the investment case.
- Roadmap realism: what the company says it can build versus what the system and team can support.
What you get
Depending on the engagement: a written technical memo, risk matrix, partner or board summary, and a follow-up call. It should be short enough to use, and specific enough to support a decision.
Why me
I have spent 25 years building and running technology companies. I co-founded and sold Openminds, built Stone Door Group's European consulting business, ran infrastructure/security/integration work at Oqton through its acquisition by 3D Systems, and now run Krane Labs for managed Kubernetes.
Not a fit
- Targets that are not technology startups or software/infrastructure-driven companies.
- Checkbox audits, compliance-only reviews, or formal certification work.
- Legal, financial, tax, or HR diligence.
- Large enterprise procurement questionnaires where you need a big-firm process more than operator judgment.
