Notes had minimal editing, please excuse brevity and typos.
Dimitra Retsina held a session about what it means to do technical due diligence.
Technical due diligence is done for different reasons and stakeholders. Can be initiated internally or externally.
Can be used to judge: is company valuation correct or not?
Also for paying party to figure out, what will I perhaps need to fix after acquisition?
I need to know everything about your organizaton.
Typically I start with a long questionnaire.
Also, an interview cycle which can be very intense.
I also ask to actually see stuff. You cannot BS your way through.
I ask the company to dust off their wiki.
Nobody has all the documentation, I don’t expect it.
What does exist is great, it saves time.
Questions we want to answer:
What is the longevity of the product? What is the quality of the team?
What are the risks? Alignment: is product aligned with management?
As auditors, we report the facts. This is the situation in the company, this is where they’re going.
On top of that, you do put some notes, based on experience: “red, orange, green” flags.
I want the effort to be meaningful for the company being audited. I suggest remedies, actionable points of advice
I help them communicate. I can help with those efforts.
I find it rewarding, have fun, taling with smart people. Great to challenge them.
Areas I look into:
- Technical modules, architecture, technology. Why? Why did you make that decision?
- CTO, development manager, developer
- Different systems they use
- The team itself
- Skills, seniority, aligned?
- Is there an API? how does it work?
- How is product built? Modular? Layers? Api? Longevity. To assess if it’s nicely done
- Is it on premise, or Saas? Saas: infrastructure. Monitoring?
- What technology libraries? What versions?
- Roadmap: alignment business + tech
- Are they forward thinking, from end-user perspective
- See some wireframes
- It’s ok if it’s transparently reported
- A roadmap often isn’t really a roadmap. Just a company goal for example.
- Architecture: tech stack. Figure out in their head, if the evolving tech is also a concern
- Often building themselves, and not replacing as things mature.
- E.g. they built everything themselves that a php framework would give them. Or: their software is full of holes
- How do they execute
- Experience of customer (i don’t usually have time to talk to them)
- About support
- Source control, backup, restore
- Can be overwhelming once you start listing them
Questions from participants:
How to improve transparency, knowledge, documentation?
HIre people with product experience
Don’t be afraid to have due diligence done, initiate yourself.
Talk with people.
What does report do? What do the red flags do?
Report helps an investor assess risks etc.
Often you can fix it, so not a problem, but now you know what to fix.