Investing in a startup is a risk, but it shouldn't be a blind risk. Investors take their time to perform due diligence before putting their money into a new venture.

They'll scrutinize the company's structure and financials. They'll challenge the business plan. For SaaS startups, they usually examine the technical side of things as well.

Technical due diligence is vital to cover product-related risks. Investing in a SaaS company without knowing what's under the hood is irresponsible. But it's also the part of the due diligence that's least understood. What do they look for?

At madewithlove, we help investors make informed decisions by taking care of the technical part of their due diligence. We do around 40 technical due diligence audits per year, so we're in a good position to answer that question: what do we look for?

Every audit results in a technical due diligence report that describes the product and how the team is building it. This report contains the concerns we see, ranging from minor to red flags. 

You can download an example of our audit report to see what it looks like. 

Here's what it focuses on:

Code quality

We don't expect to find pristine code when we look at a code base. Startups are high-growth, experimental and messy. Their source code reflects that. We look at architectural choices, maintainability, standardization, test automation and security practices.

We'll often examine unnecessarily convoluted architectures. Unprotected security credentials, outdated dependencies, tricky open-source licenses and technical documentation get a fair share of attention. We'll look for premature abstraction and undocumented frameworks. 

As software engineers, we understand that all code can be improved. The idea is not to nitpick implementation details but to uncover issues or things that might become an issue as the product starts to scale.

Team processes

Just like the code can be a bit messy, startup processes are usually rudimentary. And that's fine as long as it's fit for purpose. The governance needed to run a 3-person startup will vastly differ from a 50-person organisation.

We'll look at how well the processes and team structures match the company's current state and what limitations we expect them to face soon. That last one is vital for due diligence. The systems that work today might break as the team scales– and by definition, startups need to scale.

Like with the code, we don't care too much about the implementation details. It's not about doing Scrum by the book. We will look at the mechanisms that allow the teams to collaborate, ship, and track their goals.

Product management

You can't build great software products without good product management. Covering this product workflow is a crucial part of the audit. We want teams to leverage product metrics and user validation instead of relying on their manager’s gut feeling.  Is the roadmap realistic, and do the engineers even know where to find it?

The product part of the equation needs to be balanced, and its processes need to be set up to scale.

Examples of concerns

While interviews are good for uncovering the workflow and potential issues, they are insufficient for coming up with a real actionable solution. That's why, during these audits, we will typically not share recommendations. We list concerns– habits that might work today but will hurt the team down the line. Here are some typical concerns we encounter during audits.

  • A lack of feedback moments: The team has no formal feedback mechanisms like one-on-ones or performance reviews.
  • Missing documentation: Technical or operational documentation is lacking, making onboarding developers hard and creating a dependence on other team members which makes it hard to grow the team.
  • Secrets or credentials are exposed: API keys are stored in GitHub instead of a vault. That’s a serious security flaw.
  • The roadmap is not based on reality: The roadmap is not in sync with what developers are actually working on.

Sometimes, we uncover concerns that are already a big issue today. These acute problems are considered red flags. Examples of red flags are

  • Overengineering: Software architecture is too complex, and the current team can't maintain it.
  • Code quality: Technical debt has reached a point where it prevents the teams from shipping.
  • Overallocating resources: The team is trying to finish too many initiatives simultaneously, resulting in quality issues.
  • Psychological safety: Team morale is so low that key employees are considering leaving.

Conclusion

In our experience, the audit report rarely contains brand-new insights. In fact, if we uncover red flags the team wasn't aware of, that in itself is a red flag.

What the report does deliver is a sense of priority. We often see teams dragging a piece of technical debt with them for years. They know they should fix it, but they never give it the right attention. The report can be a good driver to finally give it that last push. Conversely, we sometimes see teams worry about not shipping fast enough while the real concern is building the wrong thing. Those are valuable insights.

It can be stressful to be on the receiving end of a technical due diligence audit. It can feel like a bunch of outsiders telling you what you've done wrong. We hope this article takes away some of that fear.

Technical due diligence is not about looking at the corners you've cut in the past. We understand that a SaaS startup is messy. After all, we see those every day. The main goal of the audit is to highlight the weak links in your current system that we expect to break in the (near) future.

It's about anticipating and addressing the risks so you're ready to scale.