Why every VC should do tech due diligence

Mark Wells

Mark Wells

The hardest working man in show business.

Every time we speak to potential customers, they tell us different variations of the same story: they’ve spent a bunch of money.

Sometimes it’s their friends’ and family’s money, sometimes it’s corporate or venture capital money. But regardless where the money is coming from, things are not working. Every time they try to release new features, everything breaks. Their code is a mess and no one knows how to fix it.

This situation is more common than some founders or investors would like to admit—the software that is so important to the success of any digital business can often be a mystery to the people who have the highest stake in its quality.

So what can you do when you’re not sure about the technical state of your product?

Whether you’re an investor looking to understand the risk of a potential investment, or a founder who’s outsourced development and is weighing up options, there are many benefits to performing your tech due diligence. In this article, we’ll cover the importance of doing your tech due diligence, and some of the things we look for when we undergo our Review process at Cogent.

Why is tech due diligence important?

Undergoing a technical due diligence review allows you to better understand the quality of your code and development processes, to subsequently inform decisions about the future of your investment. It’s a metaphorical health check-up.

The basic idea behind development methodologies like Agile or Lean, is that you can assemble a software team and produce a product prototype fairly quickly. However, as you try to expand and improve one of these quickly cobbled-together products, that is when things tend to go badly.

If there is no structure or if a product is not well-tested, then working on this product will become a very slow process later on. Conversely, if you start out with a solid structure and the right techniques (such as Test Driven Development – TDD), development will be a bit slow at the beginning; however, over time, you can change and move forward with confidence as you begin to grow and add more features.

More often than not, when you’re investing in companies, you will find yourself somewhere within this diagram above, but you won’t know exactly where—and that’s when it’s most important to perform your technical due diligence, to understand the risks carried in the project.

What to look for in tech due diligence

There are several factors to look out for when reviewing the technical state of a product. In the sections below, we’ll break down what exactly to look for when performing your technical due diligence.

Technology State

In what condition is the code base? At Cogent, we perform a thorough review and determine the code base condition using analytical tools and by manual inspection. During our review, we’ll look over the technology debt, code maintainability, automated test coverage, and infrastructure. We’ll quickly go over each of these elements below.

Technology Debt

Technology (or technical) debt refers to the additional development work that arises when short-term solutions (instead of the best overall solution) are used. Tech debt is akin to financial debt: it is okay to borrow against the future, as long as you pay it off regularly down the line.

To find out whether there is any technology debt in the project you’re investing in, look for places where the team might be taking shortcuts. If the team has taken shortcuts, do they have a plan to address those shortcuts? If there are no plans to address these shortcuts, there will be problems later on.

Code Maintainability

There’s a big difference between code that works and code that is maintainable – or scalable.

When we talk about code maintainability, we talk about something that has low complexity, i.e. something that other developers can pick up without too much trouble.

If the code is not maintainable, then it’s not easy to modify—this means that the the risk of starting a chain reaction of breakages in dependant modules is much higher.

Automated Test Coverage

Test coverage is defined as a technique which determines whether test cases are actually covering the application code and how much code is exercised when you run those test cases.

Automated test coverage gives developers the confidence of making changes without breaking everything, and it is a vital part in maintaining high-quality software.

Has the team employed test-driven development to create effective automated test coverage? If not, you might want to look into why that is.


What’s the current state of the infrastructure? Has the team thought about where the application is hosted? Is it sitting on some Cloud provider? Have they thought about security?

When we perform our tech due diligence, we review the entire system’s infrastructure to ensure there aren’t any loose ends that might compromise the integrity or the security of the project.


Processes like Test-Driven Development (TDD), Continuous Integration (CI), and Continuous Delivery (CD) are crucial within modern software development teams.

TDD relies on repeatedly turning requirements into test cases, and then implementing changes to get these cases passing. TDD often drives the design of the program and gets the developers thinking about the interface before the implementation. Once in place, automated tests then give supreme confidence to developers when they are making changes or refactoring, which equates ultimately to faster development and faster feedback from users.

CI makes sure that every developer knows and appreciates the impact of their code with everyone else’s code, within very short timeframes. If certain developers within the team are waiting two weeks until they’ve decided to merge their code with everyone else’s and then it turns out the merge has just broken everything, then that signals a lack of process.

CD ensures that if all the tests pass, the end result is put in the hands of users straightaway, for rapid validation.

During your tech due diligence, make sure to review whether the team is following any of these processes. Failure to follow processes can lead to severe conflicts, which results in delays in releases and other potential problems.

Technology Roadmap

A technology roadmap refers to a technique used to support strategic and long-range planning—it’s essentially a plan that demonstrates how your technology initiatives support your product initiatives. When we perform our technology due diligence process, we review the quality of the following elements:

Current Technology Stack

A tech stack is a combination of software products and programming languages used to create a web or mobile application.

In the beginning, your team may have made some choices around technology—they may have picked a specific language or a framework. They might have a place for how that’s going to proceed and grow. However, those decisions at the early stages are really important and can have a big impact on the success of the product later on. If, for example, they’ve picked a programming language that’s really obscure or out of date, they may not be able to find talented individuals who are skilled enough in that language.

So it’s very important to look out for a tech stack that is straightforward and ready to support the growth of the business.


When it comes to building a great product, scalability is extremely important. A scalable product not only means a product that can handle a large volume of users, for example, but also, a product that can generate a lot of revenue without adding massive costs and resources along the way.

A scalable product starts with a good plan. So if you notice there are certain elements that have not been considered in the design process (e.g. number of possible users), then that might be a red flag.


You can’t build a successful product without the right kind of people. At Cogent, when we review the product or application, we also review the teams in charge of developing the products. Here are a few things of the things we look out for, to ensure you’re dealing with a skilled and competent team.

Mix of Skills

Does the team have an appropriate mix of skills? You must ensure that they not only have developers, but developers with a good range of experience. Do they have designers and product managers working on the team? Are they working well together? A good team dynamic means good communication, which is extremely important when creating a successful product.


Good leadership can often make a big difference in how successful a team is in developing a great product. When we go through our tech due diligence, we look at the technical skills in the team as well as the people leading the teams.

Is there enough leadership to see the project through? Are there people with enough leadership experience? Skills that are highly sought after in development do not always translate to good leadership—so highly technical people do not always make the best leaders.


Sometimes, a good reputation can cloud our judgment. You might be tempted to think that just because someone has a great reputation, then that automatically translates to a great result or a great code base. However, that’s not necessarily true.

A great code base is a great code base, regardless of reputation. So, just because someone has a good reputation for something, it does not mean you should ignore the data. Always focus on the technical state of the product rather than relying on someone’s reputation.

Are you ready for your review?

Understanding what to look out for technically when you’re about to invest in a startup could potentially save you a lot of time and money. Whether you’re an investor wanting to do your due diligence, or a founder in the midst of strategic planning, a Review is a fast, low-cost way to give you an independent health-check on the technical state of your product.

If you’re unsure how to perform your own tech due diligence, there are many benefits to an independent, third-party review:

  • Benchmarked Metrics – By looking at your code using a number of analytical tools and assessing things like complexity, test coverage, and architecture design, we’ll be able to determine the quality of your code compared to best practise.
  • Awareness – In gaining awareness of the state of your product, you’ll have verified insight into how well it has been written, and be able to make informed, confident decisions about what to do next.
  • Senior Expertise – As well as using automated tools, you’ll also get a senior engineer to personally assess your code quality. In the same way that you’d see a professional for medical advice, you can rest assured that our people are experts at this.
  • Action Plan – Where your code is not up to the quality levels we recommend, we’ll give you insight into the degree of the issue, as well as ways you can start to improve things.
  • Speed – If you’re a non-technical founder or an investor about to make an investment, you can’t afford to spend months uncovering the good, bad and the ugly. At Cogent, one of our developers typically completes an in-depth Review and recommendation report within a week.

Get in touch to request more information, including a rough idea of the cost, duration, and when we can complete your Review.

Related posts

Anwesha Chatterjee

Remote Pairing – Do’s and Don’ts

Whilst pairing has been a fairly consistent part of my years as a software developer, Cogent was where I first started remote pairing. I’ve found the remote aspect of the experience amplifies certain challenges so in this post, I share some of the lessons I’ve learnt.

Read More
Sam Chalela

Deploying micro frontends with module federation and Next.js

Micro frontends are an architectural pattern that has become a hot topic in recent years for many good reasons. It has helped organisations break complex UI applications into smaller, more manageable pieces, as well as enabling teams to work end-to-end across a well-defined product or business domain whilst maintaining a consistent user experience across the entire app.

Read More