Technical Due Diligence: How to Prepare as a Startup

Although not a recurring process, technical due diligence (TDD) is often triggered at fundraising events tied to specific stages of startup growth. Most often, investors require it for seed and Series A funding so that they can validate the tech assets and the team behind them. Other potential triggers for TDD include:

• mergers & acquisitions, 
• strategic partnerships, 
• product scaling, and 
• for some startups, regulatory compliance. 

The latter includes meeting regulatory requirements such as HIPAA, GDPR, and other industry-specific standards in highly regulated sectors, primarily finance, healthcare, government, or ed-tech for minors.  

As Alex Felix, Co-Founder and CIO of CoinFund, a crypto-focused investment firm, says:

“Our diligence is two-pronged: deep technical review down to the code, and business model analysis. We adapt classic corporate finance tools creatively. Some companies earn recurring revenue from stablecoin float, others from subscriptions. At seed, we prioritize team, market, product in that order. By Series A or B, it shifts to market, team, product. The key is to avoid gut-based investing and validate every thesis with real diligence and data.”

While many startup risks revolve around market and business model, more and more investors require technical due diligence. To be exact, 70% of private investors require it from digital startups across the board. For startups in regulated niches, technical due diligence is a must. 

What is Technical Due Diligence?

When buying a home, before closing a deal, a buyer almost always asks for inspections. One would want to avoid expensive surprises or even those potentially life-threatening ones. And actually, 70% to 84% of such inspections reveal at least one problem. And also when buying a car, a pre-purchase inspection that costs a couple of hundred bucks often detects issues that will end up costing thousands. 

Just like house or car inspections, TDD is a rigorous examination of technical assets. It includes checking the codebase, security issues, architecture, infrastructure, development practices, team, and industry-specific compliance. For each of the mentioned areas, we’ll provide common issues that are typically revealed or looked for. Founders can benefit from proactively identifying and fixing them ahead of the formal process. We’ll focus on issues that are both in focus of investors and are worthwhile to fix even before TDD begins. 

The Codebase

Scrappy, fast development in the early days can be quite normal. Polishing code that might well be thrown away or dramatically rewritten in a week’s time is wasteful. However, once early feedback is in and the startup has started to generate revenues, it’s time to think long-term. 

The codebase for growth must be of high quality: reliable, easy to maintain, and extensible. This directly impacts the costs of future development, be it post-funding or simply trying to evolve the product further. In addition, it affects how easy or difficult it will be to expand the development team, such as the onboarding of new members. Finally, with an organized and maintainable codebase, there is a lesser risk of hidden bugs, and new bugs can be easier to fix. 

Generally, during the cleanup of the early code and in preparation for startup due diligence, as a founder, you’d want to make sure that there are no:

• parts of the codebase without unit or integration tests;
• hard-coded values, especially for configuration or credentials;
• a single file containing the entire critical business logic;
• undocumented bits of codebase;
• areas of the codebase without clear ownership.

So, let’s imagine the startup gets funding (or you decide to bootstrap) to accelerate product development. As new features hit release, even minor code updates and upgrades trigger unexpected errors. Investigating the issues, covering the codebase with tests, and fixing the identified bugs might take 2 engineers for 1.5 months of work. But that is not all. For these 1.5 months, no future development can take place, so you pause the roadmap. Hence, opportunity costs. As a result, efficient shortcuts in the MVP phase, without planned improvements, become a material drag on execution.

Security Issues

Secure systems are trustworthy, and with the increasing pressures on data privacy regulations, it is a must. Data breaches disrupt services and cause loss of trust. It quickly leads to financial, legal, and reputational issues. For later-stage funding, security issues can become a deal-breaker. 

When preparing for TDD, common infractions worth fixing are:

• hardcoded credentials;
• no defined roles for admin, user, read-only, etc;
• all services and users are treated the same;
• no verification of permissions for sensitive actions;
• no enforcing of authorization checks;
• no data encryption in transit and in storage;
• weak authorization flows, and more.

Whether you do TDD for funding or not, a security breach is costly. First of all, it is a senior engineer who steps in to investigate the issue: go through logs, investigate system responses, and correctly identify features and services in the danger zone. Then the work of patching and fixing the root cause begins, and for its duration, one has to disable involved features and services, take away access. Once the urgent repairs are over, the work continues in terms of adding more monitoring, security checks, and hardening secret handling. Finally, there will be a validation and cleanup stage with testing, integrity verification, and audits.

Even if it’s all done and fixed within 2 or 3 weeks, the median pay for developers involved is usually around $8k to $12k. Together with service downtime, this might put the costs of handling a security breach at 30k+, depending on the size of the business. So, security issues are always better to prevent rather than deal with. 

Architecture: Technical Due Diligence for Scale

Most funding aims to scale the startup, to put it onto the next growth stage. Architectural choices directly impact the system’s capability to scale, expand, and grow. Redoing the architecture is often a limiting and time-consuming process.

Typically, the infractions in architectural choices include:

• a monolithic approach to codebase, services, and databases;
• in modular architectures, there still can be issues with tight coupling;
• while the architecture might be modular, there is no separation of layers, such as frontend, application, business logic, data access, database, and so on;
• weak, undocumented reasoning for architectural choices.

Generally, scaling poor architecture will lead to either feature failures or performance bottlenecks. Then, the costs for reengineering the architecture will vary depending on urgency, and yet it still will take at least 2-3 months. And also, it will cost not only engineering time, but also customer churn as architectural failures lead to increased latency or timeouts throughout the system. To prevent any of that, it is best to rearchitect the solution as soon as its viability in MVP development is proven. Usually, founders track startup metrics to determine viability, and, hence, the best time to take care of tech assets. 

Infrastructure: Startup Due Diligence for Cost Control

This point of technical due diligence refers to the cloud services and operational practices – the production environment. It includes configurations, how systems and services are deployed, communication between services, data storage and its backup, and such. More importantly, while it is the code that makes the app run, the infrastructure is what keeps it up and running and does so affordably. So, infrastructure ensures the cost side of a startup’s business model.

What can the startup due diligence possibly uncover?

• Poor cost controls: no budget alerts, mix of development or production environments, poor cost visibility. 
• Single point of failure: single region of shipping services, no load balancers, no redundancy for critical services.
• No automation of server configurations, no automated backup.
• Poor resource elasticity: databases & infrastructure capacities designed for the current workload.

AWS is a widely used cloud service. Imagine releasing an elaborate onboarding feature with quizzes and uploads from users. The new feature is deployed alongside a marketing campaign. It certainly increases the traffic, and, without alerts about AWS cost, at the end of the month, the startup’s costs spike 5 times, shortening its material runway considerably.

In terms of runway, let’s assume the previous monthly spend was around 5k, and the runway leftover was at 60k after developing new features. Getting a spike in costs, it’ll put the startup at 25k cost, leaving only 35k till the startup runs out of money. Running out of money is one of the top reasons why startups fail, and operations without proper cost controls can directly contribute to that. This is why, as a founder, you’d want to have it under control even before any formal TDD.

Development Practices

Evaluation of development practices within the technical due diligence involves examining processes for code review, testing discipline, and day-to-day work on code changes. Proper development practices ensure lower incidents in production and increased development velocity. This helps the company expand its engineering team to deliver more features and updates without sacrificing quality. 

When it comes to infractions to search during the startup due diligence, these are:

• whether automated tests are up to date;
• peer review for changes on merge;
• skipping code reviews under time pressure;
• no shared standards;
• untracked hotfixes;
• open feature branches for an extended time;
• lack of regression protection;
• formalized validation procedures.

These infractions all boil down to the stability of the production build, the frequency of having to fix and rollback, predictability of the system, and days of engineering time dedicated to developing new capabilities vs dealing repeatedly with bugs, sometimes, the same bugs over and over again. Many MVPs are developed by a team of under 5 engineers, sometimes only 1 or 2. Of course, at that stage, development practices will not be an issue. However, getting Series A funding or such will often lead to team expansion and scaling. All team members will need to follow the same rules. 

Team & Startup Due Diligence

While people are at the heart of every great startup, during the technical due diligence, it is their decision-making that is under scrutiny. Engineers are evaluated based on their ownership, execution, and reasoning. Strong engineering teams avoid overreliance on key-person and adapt flexibly to new challenges as the company grows.

Potential areas of vulnerability include:

• Key-person risk when only one person is knowledgeable of the critical logic or understands the core system,
• every even a small tech decision requires the involvement and approval of the founders,
• assignment of one person without a backup to critical components,
• inconsistencies with stack choices across the product,
• no tradeoff analysis before decision-making,
• team’s capabilities don’t match the company’s stage: great engineers at prototyping might not have enough experience and skill for scaling,
• mismatch between experience: a startup in the regulated sector has a team with no such experience,
• defensiveness and reluctance to change previously made decisions,
• decisions are made during informal discussions rather than through assigned ownership.

Even seemingly light infractions, such as leaving feature branches open for long, can cause a lot of damage. Imagine getting Series A funding and starting to accelerate feature development. The team develops new features in parallel, leaving them open for weeks, and with every week, each branch diverges more and more. When the team finally merges these, it is likely to cause continuous functionality breakdowns. Obviously, the team will postpone the product roadmap to stabilize the situation.

As a result, the founders will have to inform investors whose confidence will begin to erode. They will request getting updates more frequently, pressure will mount, and slips will occur even more often. The team’s ability to ship reliably will come into question, and more negative consequences will follow. 

Industry-Specific Compliance

Compliance gaps, especially before serious funding and scaling, can result in substantial legal fees. These bear legal and financial risks that, generally, would result in postponing any go-to-market plans and lower the company’s valuation. 

For healthcare or financial apps, or any apps that store personal, payment, or sensitive data, technical due diligence will focus on the following potential weak spots:

• access controls, logs, and audits for data;
• certain data must have particular deletion and retention policies;
• data encryption;
• consent management;
• fraud monitoring, alerts, and responses;
• identity verification, verification of documentation for partners, and connected third-party services.

Let’s imagine a healthcare startup. It prioritized speed, and so compliance to-dos got postponed. The company got traction, and it is time to get the next round of funding. Once the investors realize the gap in compliance, they will not proceed with the deal until an external compliance company approves. 

While it is not critical, the funding will be delayed for several months, external checks will increase costs, and after it is done, the deal terms are very likely to be amended. Compliance issues will not stall the startup growth entirely, but they will cost time, money, and how favorable the deal with investors is.  

Final Words

Technical Due Diligence is a ticket to success in a quite practical way. Even if you don’t do it for investors, going through the checklists and doing the fixes will ensure the startup can grow safely, predictably, and productively.

Seasoned Chief Technical Officers (CTOs) often put checks and proper development practices in place even before any formal TDD process. Dealing with crises is often more expensive than preventing them. Moreover, as a rule, the vulnerabilities resurface at the worst possible timing. For instance, when your marketing department has been experimenting with creatives for weeks, if not months. Then, when one of them clicks with the platform’s algorithm and the traffic to the app surges, tech weaknesses rear their ugly heads. All in all, as soon as MVP is finished and the product starts getting traction, it is a good idea to clean up the codebase and level up the development practices. 

FAQ: Technical Due Diligence: How to Prepare as a Startup