Technical Due Diligence

What I’ve Learned from Investors and VCs

When analyzing startups, I learned about the traditional success indicators that VCs and investors utilize. I’ve also learned what metrics most VCs and investors miss when making critical decisions about where to invest. There is no room for missing data in this market, and due diligence must be thorough.

Eyeing Successful Startups

Let’s take a quick moment to label a few things that successful startups do:

• They can capture a market quickly.

• Pivot when needed.

• Satisfy their customers

• Don’t build a product from end to end before getting client feedback. After all, they’re building the product for them!

When looking for a strong startup, investors tend to look for the following:

• A strong founding team!

  • Missionaries, not Mercenaries - They want people here to build something they’re passionate about.

• A product that provides real value.

  • Existing customers are a great metric.

  • People who want what the startup is selling.

• A market with a lot of runway and room to grow.

  • A market that is open and ripe for the taking.

  • A market that is not over-saturated.

If you’re an investor, you probably know all this (and much more). But it’s important to reiterate, especially when considering the data you might be lacking.

Good Products, Bad Tech

As someone who has worked at many startups, I can attest that a tech stack can make or break an entire product. Regardless of how synergetic, visionary, and dedicated a founding team is, they might be standing on stilts if their tech is not robust.

You don’t want to build a product from end to end and in its final stage in its first iteration. But it needs to be built with sound legs. The product should have flexible joints and be able to pivot.

If you want to capture an entire market, if you want to over-satisfy your customers, a technical product needs to be able to grow and grow fast! It should be able to quickly pivot and adapt to the market it’s trying to capture. I have seen startups with robust stacks be able to move rapidly with market demands.

The Cost of a Bad Tech Stack

I have also seen startups that overextended and underdelivered. Lack of testing, spaghetti code, no documentation, lack of automation, poor architecting, and a lack of future thought are just a few reasons that products go from “adding new features to capture the market” to “we need to spend six months refactoring everything, again…”

Some companies go to market and gain traction quickly! They get a ton of clients, and their product sees immediate success. This might entice some VCs to go all in. But what if the product fits the description above? What if it is built on a poor tech stack?

They will leave longing if they cannot satisfy their client’s needs fast enough. If every time they add a new feature, it breaks, they will create frustration. If they are too slow to add new features, they will make clients impatient, causing churning. These failures can allow another company that might have moved a bit slower to overtake the existing market leader—someone with a more robust, mature tech stack.

Why You, The Investor, Should Care

In my conversation with most investors, they don’t spend much time vetting a startup’s tech stack. A few reasons for this were:

• A lack of expertise.

• A lack of in-house resources that could perform a thorough technical analysis.

• Not seeing the perceived value in such an analysis.

• Valuing other metrics over a technical analysis of a tech stack.

You should care for the following reasons:

• Even if this isn’t going to make or break a deal, knowing this information beforehand can help set more realistic expectations. You are fully aware of how fast a product can move compared to its competitors.

• Data is king. Get as much data as you possibly can on a product. If you invest millions in a startup, you can afford to spend a few thousand to get a technical report on the stack! This is yet another metric.

• When comparing two products competing for the same market, understanding how mature the underlying technical stack is can be the difference between backing the company that starts fast versus backing the company that comes out on top.

An Example

• Company A has many clients, a revenue stream, and a product in alpha mode that clients like. They seem to be the clear winner in capturing the market.

• Company B has a few clients, maybe even zero; they are still building out their product, and it’s in beta mode. They’ve let a few clients play around with it but aren’t willing to charge them full price just yet.

• The clear winner would seem to be company A.

• Now, what if I told you the following:

  • Company A has a terrible technical stack. It’s full of spaghetti code, only one person understands it (the person who wrote it, meaning they are the only person who can easily add features to it), it lacks any documentation, observability, data aggregation, or metrics, it wasn’t built to scale, and adding new features is going to be a nightmare with the current setup.

  • Company B, on the other hand, isn’t building the product from end to end or adding too many features; they’re just making sure that they have laid out the proper foundation. Something they can build upon. They have an easy-to-read code base (which will enable new developers to jump in and add new features easily), and their architecture is well-designed, so it can easily be scaled up when the time is right. They have clear visibility, monitoring, data collection, and reporting. They have everything that screams growth!

The information above might make you second-guess your initial decision. This is a hypothetical example, and there are many more factors to consider. But the point is, why skip out on capturing this data point? It can shed light on the future of a product. In a world where code is king, you must ensure the king is capable, or it can bring down the entire kingdom.

Let Me Help

Here’s where I come in. I can utilize my technical experience in DevOps, backend development, data science, and managing a team to perform technical analysis on your behalf. The analysis I provide will differ on a case-to-case basis.

An open-source project (like most crypto projects) allows for the opportunity to have an in-depth analysis of the codebase. For smaller companies with a few developers, having a couple of calls and demos might be more suitable. If they are unwilling to share the code, we can find a compromise; maybe a walkthrough of the infrastructure, monitoring stack, code, and overall architecture would be sufficient.

Small details like this gathered from the engineers and developers can help differentiate glitter from gold. A solid engineer can immediately recognize a robust pipeline from a fragile one.

Let’s get in touch! I would love to see how I can help you search for the next successful startup.