When we look at deals involving technical due diligence, we often get questions on what we’re looking for in a company. Technical due diligence is a nuanced and difficult subject, and there are many ways to do it well. This post will shed some light on how we do technical due diligence and why. 

 

Before we dive in, let’s zoom out — software engineering is hard. It’s hard to build complex software, test it, ensure it works and manage a change-to-deployment pipeline. Anyone who has done software engineering on a high-quality team knows this. Unfortunately, seldom do those people become venture capitalists! This results in low-fidelity communications, confusion about things that seem simple, and misunderstandings about what kinds of engineering problems really matter when running a business. 

 

There will always be bugs, ideas yet implemented, and technical debt. This is all perfectly fine.

 

Our approach to technical due diligence

 

Fortunately, there are no secrets here. We don’t have some obscure proprietary method of analyzing your technology or anything like that. Still, we want to find companies that are capable of using technology to meet business goals. 

 

When we do technical due diligence on a deal we’re primarily looking to answer the following questions: 

 

• Are the crucial technical decisions reasonable? 

• Is the team capable of building the technology?

• How long should it take to build this product?

 

Let’s define these criteria on your deals to make sure that you’re getting a well-rounded understanding of the product being built and what still has to happen. 

 

What are “reasonable” tech decisions? 

 

Generally speaking, reasonable technical decisions are decisions that an ordinary engineer of average intelligence would make in similar circumstances. That said, this is a startup, not the courtroom. If you’re going to beat the market, you have to make not just reasonable decisions but good decisions.

 

For example, if a startup is not using Git for version control; that would warrant an explanation. If a company is building data analysis tools using the COBOL programming language; that would warrant an explanation. That does not mean these are wrong, but that there is a practical reality of the expectations most engineers have when joining a team, so I must learn from founders on why these strange choices are the right choices. 

 

There are statistical realities about these choices too such as talent market and developer familiarity with programming languages. The TIOBE index measures how the popularity of programming languages changes with time. It may surprise you to find that the second most popular programming language is C, with JavaScript falling down at under 2%. 

 

Source: TIOBE index

Similarly to building a house, we can learn a lot about the quality of the final product by looking at the foundation and the initial choices of materials being made. Often these choices are reversible, but technical debt can linger for long periods of time, where these problems simply become larger down the road.  

 

Here’s a good example of a metric to look at in this direction, what is the cost of the entire technical infrastructure per month? 

 

If a startup is running a microservices architecture with a kubernetes cluster in google’s EKS, that alone can easily run up to $300 / month just for the cluster management itself, not including the containers! Furthermore, these costs go straight to operating expenditures and can’t be easily modified as they are integral to the product. 

Source: google kubernetes pricing 

What is a “capable” team?

 

Capability could be loosely defined as the technical feasibility for the team available to build the technology required to accomplish the business goals. We assess these as by attempting to answer the following questions:

 

(1) Can it be built? 

The first question to ask is, how difficult is it to build? A frontend tool using ReactJS is very different from generalized machine learning tooling. The next question to ask is, if it can be built, is this team able to build it? A team of mechanical engineers can’t build quantum computers.

It’s important to remember that from the outset, the only thing that separates hard-tech companies from ordinary tech companies is questions of feasibility. The best thing for grants and patient capital should be developing new research and technology until it’s ready for commercialization. Quantum computing is a great example of a field where venture capital has gotten ahead of its skis and has been funding research and development for the last decade with little to show for it outside of highly specialized use cases. 

If you have deals where feasibility is a question (for example cold fusion), you should absolutely talk to someone who has worked with nuclear fusion and can outline the pros and cons of the approach. 

(2) Can this team build it? 

Engineers can come from a wide variety of places and we would be wise to remember that a diversity of experience can be useful in the software engineering context where there are a lot of different ways to solve a problem. 

 

Typically you can get a sense of what an engineer is capable of by looking at three things.

 

(A) Experience. Unsurprisingly this is the most important thing. You want to look specifically if these engineers have experience working with:

 

• The stack the company is using for their current project (MEAN / JAM / Kubernetes / etc.)
• Startup environments 
• Loosely defined projects with little direction 
  

(B) Blog posts and portfolio projects. Blog posts speak for themselves but engineers also share portfolio projects on places like GitHub. Look specifically if they have opensource projects in the languages that you know they’ll be writing in for that role. You can filter search results with the user:filter and then by language in the user interface.

 

Some portfolio projects are proprietary yet you can still learn a lot from the achievements of the project and the evidence presented. On the other side, engineers reading this should be careful to make sure to link your github to your other resume and other public profiles, and highlight why certain projects are interesting and what you’re sharing them for.

(C) Interview process. This is something VCs don’t think much about, but it’s important to be aware of the current “standard” interview process for software engineers across the industry. Typical engineering interviews vary across the space but generally have a few components:

• A self-paced programming screen through something like leetcode  for example, the TwoSum problem. 
• An initial technical interview with an engineer on something like google docs or https://coderpad.io/. 
• A pair-programming interview to see how a candidate thinks through more complicated questions for examples see places like interviewing.io/ and pramp.com/
• A culture and behavioral interview that we’re all familiar with. 
•  

(3) How is technical competence distributed throughout the team? 

Some technical teams tend to have a single person who “knows how everything works” and other engineers go to them when they have questions on what to do. This is often called the bus factor, and it’s inversely correlated with engineering productivity for intuitive reasons. 

This is why a good thing to measure on an initial call is how good the CTO is at explaining technical concepts, and how much patience they have going through the ideas at length if needed. You should be thinking in your mind ‘would I work for this person?’

This is the only way that a larger team will want to work with them as well. If there is a small number of team members who highlight specialized knowledge (for example a Ph.D.) then you want to just make sure to double check that those individuals are sufficiently incentivized to stick around and build the business. 

 

(4) What is a “good timeframe”?

This depends entirely on the product, but similarly to the above, we want to be thinking about what the timelines actually are for building out the product at hand. 

There’s not a lot of metrics on this that I’m aware of, but building out a polished minimum viable product for a single feature or use case can often take around 6-8 months to build. Technology choices and other constraints can impact this timeline as well (using virtual machines instead of containers for a web app backend for example). Delays always happen, but you want to make sure that the team is being realistic about what can be achieved with the resources available.

With these core concerns in mind, I then look to establish some other small details along the way in my technical due diligence process.

 

Our process

 

With most companies that come on our radar, we start with the obvious things: look at the site, look at what technical roles they’re hiring for (to learn about the development stack, skills they want, etc.), and then look at the employees on LinkedIn to understand more what the interpersonal dynamics on the team might look like. These will give you a strong enough sense of what to expect on your first call.

 

With most companies, spend about an hour on a call talking with them about their product, how it works internally, how hard it is to build, and how strong they are at communicating the technical details of how the product works. Asking neobanks how payment processing works is a great way to get a sense of this. 

 

One thing that you can often do (that we’re surprised a lot of VCs don’t do) is use the product yourself. Often the team has a development environment, a sample you can borrow, or a test account that you can use. As a new user of a product you’re in the perfect position to see it from the point of view of the customer’s eyes. 

 

When all this is said and done, write up a memo of your notes and screenshots for the investment team, highlighting any warning signs or notable information with a verdict similar to the following: “The technical infrastructure is reasonable, and the team is capable.” 

 

This can take more or less time depending on the complexity of the deal, but usually one call and access to the product is enough. 

 

Managing the information relationship 

 

Before sharing our template, we want to emphasize some important details about how to think about the information being shared with investors. 

 

Information about infrastructure, languages or code examples can often feel uncomfortable to share. Founders are often reasonably wary because of intellectual property concerns, competition, and even malicious investors looking to leverage this information to compete against the business. Intellectual property ownership is great to ask about during your call, if anyone has standing to file an intellectual property claim down the road, you want to know about it. 

 

The Dubai Future District Fund is looking to enable the next wave of innovation in Dubai and grow the region as a whole. We’re only interested in using the information given to us for building a diverse economy and a better UAE. As a potential investor, you are obligated not to disclose this information as it poses a risk to their business and your reputation as an investor. 

 

The aforementioned risk often tempts founders to ask for non-disclosure agreements (NDAs). At DF2, like most venture capital firms, we don’t sign NDAs for liability reasons. These agreements can often be vague and the language is often overly broad which could subject the fund to unnecessary liability. The best way to solve all of these issues is to not share sensitive information in the first place.

 

A company should not be compelled to share anything they aren’t comfortable with. No investor needs access to source code to understand how a product works.

 

What comes next

 

After technical due diligence, you should find that you have a really good handle on whether the team can build what they want to achieve, and hopefully a good outcome for everyone in a few years.

 

We end this blog post as we began, technical due diligence is a nuanced and difficult subject and there are many ways to do it well. We want to thank you for taking the time to read through our thoughts on the matter.