Selling or Funding A Startup? Tips On Surviving Technical Due Diligence (2024)

The following is a guest post from Karl Treier. Karl is a serial entrepreneur, currently with ProspectStream and SaaS Capital. He currently blogs at The Alien Entrepreneur.

Be Better Prepared for Technical Due Diligence

I have been on the receiving end of several technical due diligence assessments instigated by VCs (pre-investment) or acquirers (pre-purchase). I have also been the inquisitor on a few occasions. So I thought it might worthwhile to write this post to share my thoughts on this process and hopefully help companies better prepare for this event.

2. capacity for survival or for the continuation of a meaningful or purposeful existence: the vitality of an institution

• Do you have a clear vision for where you want the product to be in one month, six months?
• When you advertise a programmer vacancy how many applications do you get?
• How many people have left, and how many have joined in the last year?
• Do you have people working for you now, who worked for you elsewhere in the past?
• How do you capture user feedback about the product, who sees it?
• How many releases have you had in the last year?
• What keeps you awake at night?
• Do you make interviewee's write code?

This one is pretty obvious though any assessment of scalability extends beyond the system itself to include the technical organization, and the answers to the first two questions below will indicate how the respondent thinks about scalability, not just from a technical perspective, but an organizational one also.

• What would you have to change to accommodate 10, 100, 1000 times more users?
• What would you have to change to accommodate a million users?
• What do you monitor?
• What metrics do you use to determine if you are not scaled appropriately?
• What aspects of the system do think might not scale well?
• Where are you hosted, and why?
• Do you use any third party services, what happens if they go down?
• Can you show me a network diagram?
• What single points of failure exist?
• What keeps you awake at night?
• How many open features/user stories are there, and how old is the oldest?

maintain [meyn-teyn]
verb (used with object)

maintainability, noun

1. to keep in existence or continuance; preserve; retain.
2. to keep in an appropriate condition, operation, or force; keep unimpaired.
3. to keep in a specified state, position, etc.

Maintainability is a favorite assessment topic of investors and buyers alike. They usually are either paranoid that existing staff will head for the hills post acquisition, or incoming staff will discover a plate of spaghetti code, or they want to turn a non-profitable company into a profitable one by eliminating "engineering" or they worry that a potential future investor might discover a huge plate of spaghetti code during their due diligence and not buy. In all the above scenarios there is all too often distrust of the engineering types by the MBA types and so they want to know if the code maintainable? Usually it is. You might notice many of these questions below originate from Joel Spolsky's 12 point test, which I think it's OK to plagiarize because they are just common sense.

• Do you use source/version control?
• Do you build on check-in, daily, weekly, whenever?
• Do you require comments on check-in?
• Do you create unit tests?
• Do you have code reviews?
• What development methodology do you use?
• Can you deploy a build to staging or production with one click?
• Do you have dedicated testers?
• When do you deploy?
• Does the software automatically notify you of errors?
• Do you have a bug tracking system?
• Could you walk me through some code?
• How many defects did you close last month?
• How many open defects are there?

continuity [kon-tn-oo-i-tee, -tn-yoo]
noun, plural -ties.

1. the state or quality of being continuous.
2. a continuous or connected whole.

This is typically the area where often the greatest weaknesses appear in the assessment, particularly with younger companies. There is an assumption that the Data Center will always be there, and that nothing can go wrong, that the world will always stay the same. Even everyday occurrences like a few inches of snow (or feet depending upon where you live) can cause serious disruption that should be planned for. So many of the questions below are aimed at ascertaining if the technical lead lives in a utopian world where nothing goes wrong or if they allow their utopia to be tainted by a touch of realism.

• Do you have a Disaster Recovery plan?
• Do you have a Business Continuity Plan?
• Is there any part of the system that is understood by only one person?
• Is your Version Control system backed up, where, how often?
• If the Database Server exploded how much client data would be unrecoverable?
• If a 747 crashed into the Data Center how much client data would be unrecoverable?
• Does your staff have laptops?

In Conclusion

Please don't take this as an exhaustive list of questions. Quite frankly the role of the assessor is to think on their feet and open up the questioning to explore avenues of weakness and strength. But what I do hope is that this post gets you thinking about how you would answer these questions, and what questions might get triggered based upon your answers.

Have you been on either side of the technical due diligence process before? What were the lessons you learned?