The Washington PostDemocracy Dies in Darkness

The rise of ‘technical due diligence’ in a hot market for acquiring start-ups

Before acquiring a start-up, it’s important to evaluate its code. (Robert Galbraith/Reuters)
Placeholder while article actions load

With the IPO market still a shadow of its overheated 1990’s self, start-ups and their investors are increasingly looking to be acquired by an established tech company. And with purchase prices for start-ups such as Instagram, Tumblr and WhatsApp recently hitting the billion dollar mark and beyond, an acquisition can be a win-win for both buyer and seller.

Billions for a start-up may seem absurd, but not if that start-up turns out just a few months later to be the next Uber or Airbnb, with pre-IPO estimated value of $18 billion and $10 billion, respectively.  They’re the kind of innovations Paul Nunes and I refer to as a “Big Bang Disruptor,” because they have the potential to change entire industries, and do so in short order.

But if a company is going to pay billions or even mere millions for a start-up, it had  better be certain it knows what it is buying, and equally important, be able to quickly leverage its investment.

In today’s red-hot market, an entire ecosystem has grown up around to help identify, evaluate, and integrate the start-up’s code with existing products and services.

That’s because making the right decision at the right time is critical for buyers.  Pull the trigger too soon, and you risk acquiring what is effectively still a market test, more likely to have an ultimate value of zero than of billions.  But acquire too late and you risk losing out to faster competitors, or of paying a price more-or-less equivalent to an IPO.

Beyond a traditional “due diligence” review of the start-up’s balance sheet and other financial data, buyers now include engaging long-time developers and other experts to look at the company’s technology, sometimes known as a “technical due diligence.”

Seattle-based TechDNA, for example, has been performing technical due diligence since 2010, when founder Mike Kelly, a 15-year engineering and program manager at Microsoft, left the mothership to consult for some of the teams he once led.

TechDNA has since taken its fine tooth comb to over 35 acquisition candidates, almost all on behalf of Microsoft.  The average review takes two to four weeks, with interviews conducted virtually over Skype.  Some of the companies have been as old as 10 years, others as young as four months. Yammer, an enterprise social network Microsoft purchased for $1 billion in 2012, has been TechDNA’s most high-profile review.

Kelly estimates there are about 10 companies offering tech due diligence, including some that focus on particular technical or application environments, such as automated manufacturing. (Other technical due diligence providers include Palamida, Construx, and Black Duck, which specializes in open source software.)

But why would a company with the engineering resources of Microsoft need an outside technical consultant to review products the company has already decided to buy?

The main reason, Kelly says, is legal.  Neither Microsoft nor the companies it is buying want to expose each other’s proprietary intellectual property prematurely, including copyrights and trade secrets.  TechDNA is engaged by Microsoft’s outside legal counsel, providing an outside layer of review subject to strict confidentiality agreements that protects both buyer and seller.

TechDNA’s consultants each have at least 20 years of software development experience, and the company has been expanding its technical expertise to mobile applications and services. Some have particular expertise in Apple software environments.

In a typical review, TechDNA evaluates the start-up’s software in detail, applying some automated tests that look for frequent sources of integration problems. The company doesn’t make a recommendation on whether or not to go ahead with the deal, but instead identifies architectural and organizational issues that frequently slow or otherwise complicate the process of connecting the start-up’s product to existing Microsoft offerings.

All told, a technical due diligence review covers about 60 areas of potential risk.  Many of the top problems reflect failings in basic software engineering principles, often abandoned in the rush to get a working product to market.  Kelly’s team regularly finds software code that is poorly documented making maintenance and integration more difficult. Programmers also take dangerous short-cuts, hard-coding “user names, passwords, IP addresses” and other “magic values” directly into the software, Kelly says.

Other frequently flagged issues have more to do with needs of a global software giant that differ from those of a start-up. Few entrepreneurs, for example, architect their code to easily translate user interface to multiple languages (Microsoft products typically support 20 more languages, Kelly says).

Likewise, developers don’t develop risk assessments or “threat models” to counter security breaches by determined hackers, which must be retrofitted into the code.  Operationally, they rarely have in place disaster recovery (DR) plans in the event that servers — or hosting partners — go down, potentially stranding users.

While these may not be deal breakers, Kelly says knowing in advance where the red flags are can help the acquiring company plan for integration. It also gives the start-up’s engineers—who will likely become employees of the acquiring company — a head-start on learning the kinds of standards and engineering practices that will be part of the new job.

With nearly a dozen consultants now engaged in evaluations, TechDNA plans to expand its services to other large technology companies, venture capitalists, and perhaps to start-ups themselves, helping them become more attractive targets to buyers.

But even without engaging outside help, entrepreneurs can make their companies more valuable to potential buyers just by being more disciplined about how they develop even early versions of their products.

“Most of what we see are problems in basic software engineering,” Kelly says.  “Getting that right at the very beginning is always easier than retrofitting good coding practices at the time of acquisition.”

“The times we’ve seen it done well,” Kelly also notes, “the product designer took the time to set standards and put in place design, programming, and testing rules that are easy to use.”

Which makes just as much sense for a one-person start-up as it does a billion dollar tech darling.  Especially when the differences between two gets smaller all the time.

Larry Downes is co-author with Paul Nunes of “Big Bang Disruption:  Strategy in the Age of Devastating Innovation” (Portfolio 2014). He is a Project Director at the Georgetown Center for Business and Public Policy.