This list should help you think about the various aspects to cover in a technical due diligence exercise. In my experience, no due diligence exercise follows the same script; they always take a unique path. This list can help as a trusty guide, not a script.
It really helps to request some documents from the team up front as it provides the team with the chance to think about the scope of the upcoming DD exercise. Their responses provide you with a better chance to make the most of the limited time for the exercise.
It’s crucial not to come across as judgmental or condescending. This is hard to do given your about to ask them about numerous best practices and the least desirable aspects of their baby! Show some empathy for the individuals going through DD. I find it helpful to keep in mind that I have never written and maintained perfect software, so I don’t expect this from any team. Despite your questioning, you are not trying to catch them out. The goal is to understand the opportunities and risks that exist within the solution/team so that this perspective can be fed into the overall deal context.
Some perspectives you should consider
- Describe the overall architecture of the system.
- What architectural documentation exists?
- Easily understood or complex?
- Are you using Industry standard components?
- What are 3rd parties vendors are used to make the solution work?
- What would be the next major architectural step?
- How old is the system? approximately many different people have worked on it?
- Which physical and process segregations exists?
- Do you have any load balancing in place?
- What are the single points of failure?
- How would scale the system if your load increased dramatically?
- Can you achieve automated scaling? Elastic scaling?
- Cost structures (licensing, compute, storage) – What costs scale as you scale out your system?
- What else could you automate to improve operational efficiency?
- What’s the next scalability challenge?
- What performance monitoring practices are in place? Manual, automated?
- Has there ever been load testing? When?
- Where are the bottlenecks? What is the thing that would break first under increased load
- How is sensitive information is stored in the system? How is it transmitted? (HTTPS, at rest)
- How are user passwords stored?
- Where are application secrets stored, and how are they managed (e.g. 3rd party API keys, Database passwords)
- What protection exists against common attack vectors (OWASP to 10, e.g. XSS, SQL injection)
- Any security specific infrastructure, i.e. Firewalls, IDS and WAF?
- Latest penetration testing results?
- What functions requires root access. Who has this access?
- How do your upgrade and patching software/OS?
- What’s backed up? Where? Last disaster recovery (DR) test?
- What sensitive information exists in the system
- Is the application or team certified against any standards (ISO, PCI)?
- What standards do current or prospective clients mandate, or ask about?
- What languages and frameworks have been used? Why?
- What is the structure of your Dev and Ops teams?
- How is the team organised? How do they communicate and make decisions?
- How does the team improve themselves?
- Whats source control tools, and what branching strategies?
- Unit Testing? Test Driven Development?
- What environments exists other than production? (Dev, QA, UAT etc.) How are these managed?
- Continuous Integration? Describe your DevOps toolchain.
- How do you deploy the system?
- Describe the current state of technical debt. How is this managed?.
- What version of frameworks are used? When were they last updated?
- What would you add to the development team if you had the investment?
- What operational metrics/tools are used in Production? Bugs, alerts, performance?
- Is the source code readable and consistent?
- What level of comments exists in the code? Code level, Module level?
- Are they running on current releases of underlying software? Any significant changes on the horizon?
- Are there any obscure 3rd party dependencies?
- If applicable, what effort would be required to pick up and move to the solutions to a cloud vendor (AWS, Azure, etc.)
- Any long-term viability issues with specific vendors?
- How could you improve maintainability?
- Do you own all of the code necessary to run the system?
- How is it solution licensed to clients?
- Does anyone else have (or could they claim) rights over the code?
- What are the terms for any 3rd party licensed code?
- What are the risks associated with those licenses? Are these critical pieces and could they be easily substituted?
- Are there any viral OSS Licenses embedded in the solution?
- Is there an IP strategy in place? How do you protect your IP?
- Is there a product roadmap?
- Is there a product vision? Who owns it, and how is it articulated?
- How do you prioritise features?
- What major features have been released in the last 12 months?
- Are metrics or tools used influence the product direction?
- How do customers influence the product direction?
- What else is essential for a potential investor in your software to know. What could affect the system in the future?
- With a significant resource investment (money, people), what would you do to the application or the software delivery team?