Published in


Venture Capital Due Diligence: Technical Due Diligence

Co-Authored by David Awad

This is part of GoingVC’s Research Series on Venture Capital Due Diligence

Introduction | The Screening Process | The Market Test | The Scorecard | The Management Test | The Management Team | Product KPIs | Building Product Moats | Accounting 101 | Financial Valuation | Technical Due Diligence

What is Technical Due Diligence?

Many VCs and founders consider the company’s technology a potential competitive advantage. For VCs performing due diligence on companies that rely on a tech platform as the primary company offering, technological due diligence is something to consider. It is important to include a caveat here that at the earliest stage of a company, the product is likely to be incomplete (if existent at all) and have with it the highest probability of being different than what the go-to-market product looks like, so always take technical due diligence with a large grain of salt.

A key to technical due diligence is a bit of juxtaposition in that it is more important to assess the execution risk of developing and bringing the technology to market than it is actually assessing the technology itself. It can be the best piece of technology in the world, but if people don’t like it or it doesn’t solve a problem, it’s not worth anything.

As Point Nine Capital alludes to, two axes on which to assess the tech and product team are:

  • Speed: An ability to iterate quickly enough to get the product into customers’ hands
  • Reliability: An ability to build a product that works at scale

To understand where to plot companies on this scale, due diligence should cover the following:

  • Who: VCs need to start by understanding the capabilities of the individual(s) and who is responsible for building what.
  • What: In what state is the product today (idea, MVP, Beta, At Market, etc.) and what are the immediate next steps for the development, testing, and feedback cycle?
  • Why: What technology stack has been implemented and why? What trade-offs were made with these decisions and what is the degree to which these trade-offs and choices might introduce risk or need for changes?
  • How: What has been the development path to this point and more importantly, what is the product roadmap moving forward?

Within all of these needs to be an attempt to understand what potential competitive advantages may exist within the technology. Typically, those who reach market first and establish product-market fit increase the odds of success, so how likely is the team in being able to achieve that given the answers to the above? Are the right people in the right roles? Does the roadmap make sense in terms of solving the critical problems facing customers?

Some examples of red flags may be SaaS companies that have only thought through developing a product for one set of users (i.e. one side of the platform), engineers developing on older technologies (i.e. developing websites in PHP), or product teams incorporating features without listening to end users (product bloat and out of scope). Are these absolute company killers? No. But having a framework to effectively scan for landmines can avoid major blowups down the road.

“Our job is to figure out what they’re going to want before they do. I think Henry Ford once said, ‘If I’d asked customers what they wanted, they would have told me, “A faster horse!”’ People don’t know what they want until you show it to them. That’s why I never rely on market research.”

Steve Jobs

Another balancing act to keep in mind exists between trying to get a product into potential customers’ hands quickly and working too quickly, making too many shortcuts and putting out a product too soon. VCs should look for product development iterations that make sense. How much of the product development has been driven by user feedback versus internal dialogue? Not everyone can be as forward thinking as Steve Jobs when it comes to product development.

A Framework for Technical Due Diligence

As a general rule, given a startup is a combination of a team, a product, and a market for that product, what we want to determine with technical due diligence is “Is this team technically capable of building this product, for this market?”

This means it is okay for the processes and infrastructure to be unrefined, as we only need to be confident that the founders have the technical understanding and knowledge to quickly iterate on the product as it needs to exist for the market.

Therefore, there are three possible determinations when assessing the technology within the product: technically sound, workable, and what we’ll call ‘Here Be Dragons’:

  • Technically Sound: The product is well maintained, there are good automated tooling and build processes in place, there exists a good infrastructure, a clear delegation of responsibilities among team members, lots of documentation, and low bus-factor.
  • Workable: This is where most companies fall as there is significant technical debt but the knowledge to improve on it and the team is most certainly able to do the work.
  • Here Be Dragons: Where there are teams that really do not have the technical knowledge or infrastructure in place to be able to successfully iterate on their product for the market they wish to serve.

Below is a basic set of criteria VCs can use to assess a company’s product technology, capabilities, and roadmap. In addition to the below, it is prudent to write a short summary detailing the average monthly cost of running the technology (i.e. cloud and domain hosting costs, data center costs, etc.) and how customers interact with the product (i.e. via web, mobile, API, hardware, among others) to create a customer touch-point or journey along with the associated costs with supporting those customer needs.

Technical Infrastructure (Detailed)

Next, we develop a framework for assessing the technical infrastructure, drawing on the Assessment, Learning, and Teaching methodology ascribed by VC by Rodrigo Martinez of Point Nine Capital.


The Assessment concept begins the analysis by understanding how the product was built. It is important to take into consideration not only the progress and technology but whether or not the business model works for the market, and if the technology and product support that model. For example, how critical is a native mobile app in addition to a web app? Does the team need both or would a mobile-responsive website suffice? Below are the critical points to assess and key questions to ask:

Code ownership: Inhouse vs Outsourcing

  • Are they using contractors or outside developers to build their product?
  • How do they think about code quality?
  • Do they have technical specifications in place?
  • What are the agreements when it comes to ownership of the IP when it comes to outsourcing?

Agility: Speed vs Reliability

  • Are they using version control?
  • If so, does it allow for rapid deployment of product changes?
  • Do the tech stack and programming language(s) have a large community of supporters?
  • Is the tech stack open source?

Monitoring: Understanding All vs Little

  • How much clarity and insight do they have into how the product is being used out in the world?
  • Does the product include tools like Mixpanel to track and analyze beta users and segments?
  • If the product gets taken down, how quickly can they find out why?

Compliance and Security: Risks

  • What kind of information and metadata will the product collect, use, and/or recycle?
  • What is the level of security that this product needs to have?
  • Does this team have that level of security knowledge?
  • What kind of rewards does a potential adversary gain by getting access to this information?

Scalability: Ready Now?

  • How scalable is the product today and what is the plan to make it scalable?
  • If the product hits #1 on Hacker News tomorrow, are they ready for that?


Startups are constantly learning from a myriad of sources. Those that can most efficiently distill the information and develop actionable plans will get to market first and develop products that incorporate all the necessary feedback. The learning aspect of Technical Due Diligence covers how rapidly the team can operate within that cycle.

Intellectual Curiosity and Thoughtfulness: Ability to Perceive and Handle Challenges

  • How aware of the challenges to come is the team and how prepared are they to be ready to solve problems in the future?
  • How can the product be misused?
  • Are there safeguards in place against misuse?
  • What do they do in response to production downtime?

Processes and Tools: Setup for Success?

  • Is the product in a place to achieve high productivity? How is that measured (what goals and OKRs are in place) and how far into the future have goals been set?
  • How adequately have past goals been measured and to what degree have they been met? Why?
  • What does the development environment look like? Do developers use code formatters or similar interfaces?
  • Is there a style guide in place?
  • How many different programming languages are in use?
  • What code quality measurement tools are in place?
  • Where do they host their code base? Who has access to it?

Organization: About Stability

  • Is the organization setup to avoid friction and align goals?
  • Is it obvious who makes technical decisions at the company?
  • How are the responsibilities over different parts of the infrastructure divided among the existing team members?


Many technical leads might scoff at the notion of developing talent in addition to products. Having technical leaders who can teach, coach, and mentor can be an important factor for success.

Leadership: Teaching by Example and Communication

  • Is the technical founder able to, for example, sit down and teach you how Linux file permission bits work in an effective manner?
  • Do the technical leaders have a strong ability to communicate technical terms to laymen?
  • How important is technical documentation and version control to the technical owners?

Hiring: Attracting Great Talent

  • Understand what the key needs are (and why) and how the technical leadership intends to fill those needs.
  • What hiring resources and talent pools are available? How likely are they to be able to bring on top talent?

Managing: Motivating and Keeping that Talent

  • What incentives are in place compensation-wise and non-compensation wise (i.e. personal fulfillment within the job)?
  • Is there a clean plan for setting goals and reviewing progress over time to identify future leaders?

The Takeaways

In summary, keep in mind that technology itself is rarely a needle-mover. As tech continues to move towards an open-sourced, API-driven environment, having a technology infrastructure that is ‘closed’ is rarely an advantage to developing products — technology is best used as the means to an end.

So how critical is technological due diligence? At the earliest stages, it is less so than later stages (when it needs to prove it can scale). It is more important to be able to assess the quality of the teams, how aligned the product is to the customer’s ability to solve their problem, and how scalable the infrastructure is more than how advanced the technology is in most cases.

Get VC research and insights delivered directly to your inbox! Subscribe here.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store