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

Written By: Dharmesh Shah February 28, 2012

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.

The first thing to recognize is that the assessor is not there to catch you out, trip you, up or somehow prove you are incompetent, nor is it likely that he's there to try steal your job, so first and foremost don't be threatened or intimidated (it's not the Spanish Inquisition, after all "Nobody Expects the Spanish Inquisition"). It is however extremely likely that he or she is, or has been an entrepreneur and empathizes with you, so be cooperative and cordial (maybe even down right friendly). They will understand the challenges and the realities of startup, rampup and speedup life and are not expecting perfection. I personally would love it if every entrepreneur could get funded, or exit with an acquisition that gets them the rewards they have worked so hard to attain, but the reality is different. Remember however the assessor is contractually obligated to do a thorough evaluation and report honestly any deficiencies, to not do so would risk a lawsuit for negligence. Also keep in mind that the purpose of an individual doing this, rather than have the investor or buyer just deliver a survey to you for you to complete, is that they are evaluating you and your team, how well you think on your feet, how you engage, and your thought processes. So expect it to be an interactive conversation, more than an outright quiz or exam, which would be painful and boring for both parties.inquisition

In my opinion the primary purpose of the assessment is to evaluate four facets of your business from a technical standpoint, Vitality, Scalability, Maintainability and Continuity. Vitality, really? I'll admit no one has asked me to go assess the vitality of an organization, but I'll explain in the next paragraph why I use that word because I think it fits perfectly with what I'm looking for. I'll precede each section with the dictionary.com (edited) definition of each of the four words so you see just how well they fit the goals of the assessment, a narrative of the objective of assessing that characteristic of the business, and a list of questions you just might get asked.

vitality [vahy-tal-i-tee]
noun, plural -ties.

1. exuberant physical strength or mental vigor: a person of great vitality.

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

3. power to live or grow.

So what am I looking for when I assess the technical vitality of an organization? Really I'm looking to see first and foremost if the technical lead or founder is still excited about the business. Does he or she have a real vision of where to take the product next, are they a fountain of ideas. Sometimes the original technical founder(s) may have left, so is the replacement a caretaker, or do they have their own ideas of where to take the technology and business. In my opinion this is a very important thing to assess. The best and fastest growing software companies in the world have great technology leadership. You can't build great software companies with only MBA's at the top. Yes you need the MBA types, but you also need the engineer types that can see emerging technologies and see how they can be applied to the product to further the business. The truth is that great technical leadership also attracts great technical talent, which is essential to the vitality of the company, and essential to ensuring all the other bases we will discuss below are covered. Here are some questions you might get asked which really assess the vitality of the organization.

  • 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?

scalability (ˌskeɪləˈbɪlɪtɪ)
noun

1. the ability of something, esp a computer system, to adapt to increased demands.

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?

Related Posts