What does technical due diligence mean for a startup?

Technical due diligence is the process of validating the technology assets, risks, and liabilities associated with a startup. A minimum viable product (MVP) is an example of a startup technology asset. Risks often take the form of technical debt, capability gaps, or deficiencies; certain forms of risk may also represent liabilities.

What is the goal of technical due diligence?

The goal of technical due diligence for a startup is to assess a product or service's systems and infrastructure for potential risks, weaknesses, or gaps. You do this to catch anything that could hinder your company's growth trajectory or compromise its ability to deliver on promises to investors, customers, and partners before it's a problem

Technical due diligence is one part of the assessment performed by an investor on your startup. In addition to the technical aspects of your startup, investors will also perform legal, financial, and other related due diligence activities. If your startup has not yet been through technical due diligence, it may be only a matter of time before an investor will ask for this to take place.

With technical due diligence, an investor wants to understand and validate the technology assets, risks, and liabilities associated with an investment opportunity. Are the technology assets as described? What are the scope and scale of any associated risks? All opportunities have risk, and an investor will calibrate their level of due diligence to meet their investment risk profile. Finally, which risks present themselves as current or potential future liabilities?

Incubator-stage companies are mostly idea-driven, in which case the investor may be interested in understanding technical feasibility or evaluating an early prototype. Accelerators, such as LogicBoost Labs, will be looking for the foundations of a go-to-market business, which implies a solution at the MVP stage or beyond—one that can improve functionally and operationally over time. Series A or later-round investors will be looking for specific levels of technical maturity, such as well-defined processes and appropriate levels of technical debt—along with a roadmap to eliminate any remaining serious liabilities.

Congratulations!

For many startups, their first encounter with technical due diligence is when an investor is sufficiently interested in their startup and wants to explore the next steps. As with all early-stage companies, there is no convenient time for yet another must-do item. The time for preparation will often be inadequate and rushed. As such, technical due diligence is often thought of as inconvenient, and rightfully so in an overloaded mindset. However, we will try our best to show that this does not always have to be the case.

Understanding the basics of the technical due diligence process goes a long way toward focusing priorities, reducing apprehension, and maximizing the chance of a successful outcome.

The basics of technical due diligence

While technical due diligence can come in all shapes and sizes, there are several common patterns in use. The investor may have a senior technologist on staff, and this is the person who conducts the due diligence. Or they may contract out to a third party to perform the due diligence evaluation. In either case, anticipate one of the two evaluators”

1. The evaluator is a senior technology generalist and may have no specific knowledge of your technology stack or domain. You will be the expert in the room for many details. However, do not be lulled into a false sense of security since the evaluator’s deep experience often comes with equally penetrating questions.
2. The evaluator is a specialist in your technology stack/domain. In this case, be self-aware of your limitations and do not overstate your knowledge and capabilities.

Understand the plan once your technical due diligence is scheduled

Who is the evaluator, and what is their background? (Hint: LinkedIn can be helpful here).

Do they provide any preparatory documents, checklists, or questions?

Is there a meeting agenda?

What topics are expected to be covered? If so, do your best to prepare and organize your thoughts and supporting material in kind.

Also, be prepared to give a brief product demo up front. If this all comes at the last minute and you have little to go on, so be prepared for anything. See “In Case of Emergency Break Glass” below.

Control the things you can

Make sure any senior leadership in the meeting is on the same page, specifically reminding them this is not a sales pitch! Also, make sure the right technical people are in attendance and, if anything, error toward overcompensating and covering your bases on the technical front. Deconflict calendars so that no one feels unduly rushed or is absent.

But, most notably:

• Do not apologize for anything. You are not looking for resources because everything is already solved. Even big companies have deficiencies and skeletons in their closets.
• Do not blur the lines between what exists and what is planned or aspirational. Keep sales speak in check. “Real self vs. ideal self.”
  
• Be confident—you are the domain expert. However, do not exaggerate the skills or capabilities of your team.
• Make certain someone from your team is taking detailed notes.
• Relax, have fun, and make it a learning opportunity.

If your solution incorporates or is based upon current hype-cycle technologies, such as AI/ML (artificial intelligence/machine learning), blockchain, cryptocurrency, or the like, be prepared to tell your story and usage in exacting, factual detail.

The best evaluations end up being a positive learning experience for both parties, sometimes even a mini mentoring session, depending on the dynamics at play.

The evaluator may be unprepared, poorly qualified, or otherwise not a good fit on rare occasions. Do your best and learn from the experience. If the potential investor is unaware or unconcerned with this situation, that may be a warning sign that required additional scrutiny. Remember, you need to do your due diligence on the investor as well!

Due diligence personas

While most technical due diligence encounters will be highly professional, some personas are worth calling out in the interest of improving your preparation:

• The Genius The most intelligent person in the room. And happy to let a captive audience know that for the next two hours.
• The Lawyer Latches onto an inconsequential point and will not let go. You feel like you are under cross-examination in a criminal trial. They completely lose sight of the bigger picture.
• The Accountant Efficiently yet dispassionately gets through their checklist. You are unsure if they understand your business at the end of the conversation. However, the report will be comprehensive.
• The Favor Investor knows a friend that knows a “tech person” and calls in a favor. A complete wildcard. You could get lucky, and they are just the right person. Or you end up politely explaining how basic things work. Or anything in between.

If you are thrown any of the above curveballs, do your level best to keep it professional, on topic, and to leave the best impression possible, under the circumstances. How you are treated here should be a factor in your evaluation of the investor.

Technical Due Diligence Preparation

Preparing for technical due diligence should be thought of as writing a term paper. You would never consider writing a term paper the night before it is due, at least if you are expecting a good outcome. It pays to start early, well in advance of any first due diligence conversations.

The best guidance for technical due diligence preparation is to learn to love to document. Document early and often. You do not need to be a Shakespeare or Hemingway. Often the most effective documentation is captured as summary notes and diagrams.

Make sure to keep this documentation in a location centrally accessible to your organization. The most important use of this documentation is for your ongoing operations—it should describe how your product is built, deployed, and maintained. For our purposes here, it also conveniently happens to be a primary source for technical due diligence. If you’re behind the documentation curve, as many startups are, take action to minimize the gaps.

As early as practical, start a technical due diligence deck. On day one, it will consist mainly of placeholder slides. However, try to fill in the essentials quickly. Make sure to link to all available backing material and periodically revisit to update. Also, remember that “a picture is worth a thousand words.” Architecture, system, workflow, navigation, and other diagrams are invaluable and can simplify communication.

Here is a quick spot check: if you were to hire a new development resource, how would you most quickly and efficiently get them up to speed? Much of this is precisely what is needed for technical due diligence as well.

The technical due diligence deck is a living document. Over time, it is not uncommon to compile a deck with 50 or more slides. Since you will never go through this many slides in any single due diligence sitting, have the core dozen or so slides upfront while making sure to keep the unused slides as supporting material at the end.

Should additional information be available, be prepared to adjust the deck to best suit your audience. If possible, share this deck with your evaluator after the due diligence meeting. This will help them provide a thorough and accurate evaluation, filling in any gaps from their note-taking or recollection—or to focus on any follow-up questions they may have.

It is also helpful to seek external feedback for your technical due diligence deck. Identify a trusted technical resource who can provide feedback and positive criticism of the materials you have gathered to date. Inputs from a “red team” viewpoint, representing a tough evaluator, can dramatically sharpen your deck and talking points.

In Case of Emergency Break Glass

The above preparation guidance is all fine and good, but it can often be the case that you may not be as well prepared as desired. Early-stage companies are often armies of one, two, or few, and little time is set aside for the predatory work.

If you find yourself in this position, here are some pointers that can help deliver the best possible impression under the circumstances. You will still need to set aside a few focused hours to gather your thoughts and compile basic supporting materials.

• Do not plan to go through a technical due diligence discussion solely conversationally. Always have some supporting materials on hand. No supporting materials lend the impression you are unprepared.
  
  
• Supporting materials can be a presentation with several slides. These slides should consist of the items below. Expand on these as you have time available.
  
  • Technology stack
  • Third-party integrations/SaaS services in use
  • High-level architecture diagram
  • Tools used (project management, documentation, source control, deployment, etc.)
    
    
• Since your supporting materials will be light, offer to walk through the details of your product planning, development, and deployment process. In today’s world, this will be through screen sharing, so have browser tabs open and be ready to share. Show the actual items behind your slides: project management tools, cloud console, documentation, source code, etc.

Recognize that this is a less-than-ideal circumstance, but this approach is always superior to just “winging it.” While the due diligence discussion is still fresh, sit down with your team and plan to get ahead of this the next time around.

Post-technical due diligence

Successful technical due diligence is often a gate to further discussions with a potential investor. If you get a call back to continue forward, congratulations on a job well done! However, do not celebrate too soon since you will most likely need to gather documentation and artifacts that support your claims and publish these into a shared data room. Your technical due diligence deck will be a primary document. Note that a data room context may require additional care since these items will be viewed standalone without your narrative alongside.

If you are asked for additional technical follow-up, do not get too excited, but think positively. Make sure to get follow-up questions or areas of inquiry in advance so that you can prepare well for these follow-up conversations.

The sad truth is that there is much rejection in this process. Chalk it up as a learning experience. Do your best to find out if technical due diligence findings were part of this rejection. You may have to push for details politely. Note that not all investors are willing to provide a level of actionable detail in response. Consult your notes (from above) and see if you could improve anything else.

In all cases, make sure to continue documenting and keeping your technical due diligence deck up to date.

Technical due diligence checklist

Below is a condensed sample of a technical due diligence checklist suitable for startups with an MVP-level product. Your specific technical maturity level, combined with investor needs, may require different or additional items to be addressed. This checklist is by no means exhaustive, but you can use these to seed placeholder slides in your technical due diligence deck, backfilling and maintaining them over time.

• Team composition and responsibilities
• Features and capabilities overview
• Product roadmap
• Technology stack
• Architecture/system/workflow/navigation and other diagrams
• Processes (Scrum, Kanban, or variations)
• Documentation repositories and their use
• Inventory of all third-party SaaS services in use
• Source control and any branching/workflow strategies in use
• Build/deployment processes (manual/ad hoc, CI/CD)
• Release checklist, quality assurance processes
• Monitoring and alerting
• Scalability, identified single points of failure (SPOFs)
• Known security concerns
• Administrative tools and automation
• Customer data usage, analytics, security, and privacy
• Backups, disaster recovery
• IT security and practices
• Any identified critical gaps or needs (e.g., missing features or deficiencies that are causing significant issues today)
• Current challenges (items you have a tough time with now and would like help/resources to resolve)
• Identified technical debt, particularly high interest (e.g., a part of your application that will need to be refactored sooner than later)
• Current and future technology needs (staffing, platforms, services, capabilities, etc.

Conclusion

Successful technical due diligence requires careful planning and preparation. Understanding the process can help defuse many uncertainties and provide focus on the items that matter most. Building a culture of documentation is a crucial component of this success.

In a startup, this can be challenging and requires a certain amount of discipline. However, the benefits are clear—for both technical due diligence and, most importantly, to accelerate operational efficiency as your company grows. We have yet to find a company that regrets having adequate documentation on hand.