How to handle software due diligence

(This article is also published on startup juncture, my new blog on startups together with three other authors. Please check for this and other stories.)

‘Due diligence’ is an M&A term for any investigation that the buyer does to know what he/she is buying (like wine tasting, but for companies). Startup founders typically encounter ‘due diligence’ as a time-consuming activity when they want to sell (part of) their business. Typically a due diligence is done at least on company legal structure, tax liabilities, financial numbers, the business plan, market assumptions, and for large older companies also on pension obligations that are not accounted for. More recently, many buyers insist on a software due diligence: a review of the software of the company to be bought. In this article we help you as a founder manage the software due diligence phase.

Tip1: consider an independent party
Sometimes when you are selling a company, buyers request that you send them the software in advance so that they can do a due diligence on it. If the software is valuable you obviously do not want to do this. If no deal is closed, the potential buyer could become a competitor and you do not want them to have access to your software. The best way to get around this, is by proposing that the software due diligence is done by an independent party. I work with the Software Improvement Group, where we have done many independent and objective software assessments, in many European countries (The Netherlands, Greece, Denmark, UK and Germany). At SIG we use a software lab to make sure we can cover many different technologies. Another company that does audits is Black Duck software.
Depending on the size of the deal, you can also ask an independent professional. In this case, you must check that the individual has knowledge of the relevant technologies.

Tip 2: agree to a due diligence, but at the end
Buyers may want to do a due diligence before closing negotiations, for instance so they can use any negative outcomes to lower the price. This is not helpful, because it slows the negotiation process: a software due diligence leads to many detailed findings that will have to be interpreted by both parties.

Refusing to have a due diligence on software you own is definitely a right that you have as a seller. However, this does not help in building confidence in your software or closing the deal. Instead, you can agree in the final agreement that a software due diligence will be done and that the seller can reconsider the deal if major risks are found. This way, the software due diligence does not slow the negotiation down.

Tip 3: ask the right questions
A big risk of any software review is that technical findings are misinterpreted and become major issues in the minds of nontechnical managers. Any significant software system will have ‘format errors’, ‘illegal exceptions’ and ‘suboptimal queries’. This does not mean that the software is not suitable. To prevent this problem, make sure that the software due diligence is aimed at answering a limited set of relevant business-level questions. Good questions for instance are:

  • What, if any, defects can be found in the software that require more than 1 FTE in repair effort?
  • Does the software have any quality issues that affect the business case by more than € 100k?
  • If any significant risks can be found related to the software, how can the future maintenance team resolve or handle these risks?

Having such questions will make sure that all recepients of the due diligence report will draw the same conclusions about the business consequences of any findings.

Tip 4: install a deadline
Make sure you limit the total throughput time of any due diligence effort on the software, for instance by agreeing that the buyer has until February 1st to complete any due diligence activities. By setting a deadline you make sure the process keeps moving.

Tip 5: ask for the results
If you allow an expert to look at your software, insist that you also get a copy of the final presentation or report. This allows you to check that the investigator was competent and has indeed only focused on the relevant questions. If necessary, you can provide explanations for any unusual findings.

These tips should help you to get the due diligence done and complete the deal. In many cases, the fact that you are willing to participate will already indicate to the buyer that you trust your own software. And if not, remember that due diligences are just like police traffic checks. Annoying if you get help up by one, but very useful in general.

This entry was posted in Other articles and tagged , , , , , , . Bookmark the permalink.

One Response to How to handle software due diligence

  1. Jim Hoffman says:

    This is a good overview of the process. A free, very detailed checklist is available at The sample content from the book also includes a review of the due diligence request process from a hands-on perspective.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s