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

About This Blog

This site is for  entrepreneurs.  A full RSS feed to the articles is available.  Please subscribe so we know you're out there.  If you need more convincing, learn more about the site.



And, you can find me on Google+

Connect on Twitter

Get Articles By Email

Your email:


Blog Navigator

Navigate By : 
[Article Index]

Questions about startups?

If you have questions about startups, you can find me and a bunch of other startup fanatics on the free Q&A website:

Subscribe to Updates


30,000+ subscribers can't all be wrong.  Subscribe to the RSS feed.

Follow me on LinkedIn


Current Articles | RSS Feed RSS Feed

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


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 (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ɪ)

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?

Posted by Dharmesh Shah on Tue, Feb 28, 2012


Great Post! This was very helpful especially for an "MBA Type" who is founding a tech company. There were many questions that I don't know the answer to about my own company. So i will be able to use these questions with my Tech Co-Founder to asses the same questions about my company.

posted on Tuesday, February 28, 2012 at 9:36 AM by Don Tarinelli

Wow! great post. Am a technical co-founder and CEO of Looking to raise funding and was wondering what all is covered in a technical assesment. Now I have some answers and todos ;) Forwarded this to the two tech leads(and co-founders) 
Thank you!

posted on Tuesday, February 28, 2012 at 10:01 AM by Ayush Ghai

Hi - Good framework and questions. Reminds me of being on the receiving end of a number of week-long enterprise IT audits at HP - "Hi, we are from Corporate, and we are here to help you." 
The fact was, they really were there to help. That's an important hurdle.  
It helps to LET them help. Do not get defensive. Throw the DD investigator a bone now and then.  
Also, the purpose of a startup is NOT to pass technical due diligence. It is a technique, a method. It is not a operating code.  
Also, beware of overbuilding your startup. Too many startups build-out a monster platform they don't need (yet). It is at the expense of customer focus, growth and other uses of scarce capital. Allow your internal policies and procedures to meet and just exceed customer requirements.  
VSMC is a good framework. At HP we used/invented FURPS. 
Back in the day, I extended it to FLURPS - L = Localization.  
Bonne chance! 

posted on Tuesday, February 28, 2012 at 12:04 PM by John Maloney

I've been at one or two Silicon Valley startups that were on the receiving end of due diligence by VCs. The financial due diligence was pretty serious but the technical due diligence was widely considered a joke. I think that the VCs mostly didn't understand the tech stuff and, if your financials were good, they figured that you could hire whomever you needed and eventually fix the technical flaws. So, technical due diligence mostly consisted of reporting whether the startup used a MySQL or Oracle database and how many rows were in the database. 
Continuity is certainly a good metric but practically no startup around here passes any of that. Even large and famous companies run out of one location more often than you might think (although this is changing fast with cloud computing). 
As an industry, Silicon Valley relies heavily on the "thousand flowers" theory. Promising companies don't win because they react to disasters well; they win because they get lucky and no disasters happen to them (or, like Twitter, customers hang in there despite significant disasters). 
But that's just the Silicon Valley. YMMV.

posted on Tuesday, February 28, 2012 at 4:41 PM by Dan Howard

As a start-up operator, it is my obligation to make the assessor successful -- success being defined as an accurate assessment of who we are, what we deliver, what we own, etc. etc.  
That being said, if one perceives that the assessor has an agenda beyond his or her appropriate mission or is simply not capable of performing the task at hand, then there's no choice but to bring in the principals and get the assessor either replaced or reoriented. And, there's no benefit to waiting. Raising the issue after the fact will sound like "sour grapes."  
I'd be curious about the experience of others in such a situation.

posted on Tuesday, February 28, 2012 at 4:53 PM by Andrew Ellis

Awesome Article! Thank You :))

posted on Tuesday, February 28, 2012 at 4:58 PM by Pedro Pereira

Dan, flaky tech due diligence isn't restricted to SV, I have been on the end of a couple that were laughable too. I agree I wouldn't expect a startup to be multi-location hosted but I do expect to see a plan for what would happen if that location failed, and I see too many startups with massively duplicated HW except for the solitary Network Switch everything is connected to! 
Andrew, absolutely, if you detect an agenda raise that concern immediately. I have seen due diligence teams who clearly were angling for one of the CxO jobs post acquisition. 
Thanks for the comments.

posted on Tuesday, February 28, 2012 at 5:22 PM by Karl Treier

Great piece as usual. 
Helps entrepreneurs understand the dd process and also the tech issues that can be a concern area. 
Thanks again.

posted on Wednesday, February 29, 2012 at 1:52 AM by Raj Mohan

Great information. You did two things, made it simple to understand the process and removed much of the anxiety (fear) surrounding the process.

posted on Wednesday, February 29, 2012 at 1:51 PM by Steve Farfsing

Excellent post! I would add "Clarity" to the key facets of an evolving technical solution that should be highlighted in due diligence. Perhaps this is an element of vitality, but having technical "vision" aligned across the organization (sales, strategy, tech, etc.) is critical. Additionally, questions that cut to how well the customers "get" the technical integrity of the solution (and how well the tech team "gets" the customer) are the most challenging for companies that are still trying to reach scale. Case in point: My first start up passed tech due diligence with flying colors through three rounds - and the disconnect with the customer (and the sales and marketing teams) only widened.

posted on Thursday, March 01, 2012 at 10:19 AM by Brian

This is a very well written post..

posted on Saturday, March 17, 2012 at 6:47 AM by Amith

Comments have been closed for this article.