Technical Due Diligence in SaaS Acquisitions: What I Look For

When evaluating a SaaS acquisition, my main goal is to understand what it will take to maintain and operate the application after handoff. I want to know what I'm inheriting, what needs fixing, and whether I can realistically move the application into maintenance mode without spending a significant amount of time keeping it running.

Since we're managing a portfolio of software businesses, it's important that each application can be maintained without requiring constant developer attention. My target is three hours or less of development maintenance per week once an application is in maintenance mode, excluding new feature development and planned technical debt cleanup.

The following outlines how I approach technical due diligence and what I want to understand before taking ownership of an application.

1. Understand the Codebase and Architecture

I start by reviewing the codebase to understand the tech stack, including the languages, frameworks, libraries, database, and other tools used to build the application.

The first thing I look at is the existing documentation. Even a basic README gives me a starting point for navigating the codebase. Ideally, the architecture and important technical decisions are documented so someone new can understand how the system works without having to figure everything out from scratch.

If documentation is lacking, I can use different LLMs to analyze the codebase, answer questions, and help me understand the architecture. I also want to identify any unsupported frameworks or libraries that could cause problems down the line.

The tech stack itself isn't the most important thing. An older application can still be a good acquisition if the architecture is solid and the code is maintainable. What matters is whether I can understand the system and confidently work on it after handoff, rather than the application depending entirely on the person who originally built it.

2. Evaluate Security and Reliability

For security, I would use our existing Blueprint security best practices as a baseline and leverage LLMs to audit the codebase against them. Our checklist covers areas such as CSRF protection, rate limiting, input validation, SQL injection prevention, XSS prevention, session security, security headers, secret management, and encryption of sensitive data at rest.

Manually reviewing every security concern across a large codebase takes time, especially when acquisitions can move quickly. Using AI to perform a broad initial audit helps identify potential vulnerabilities and gives me a starting point for investigating the most significant risks. I wouldn't treat an AI-generated assessment as proof that an application is secure, but it can help prioritize what needs a closer look.

For reliability, I would review historical uptime data, incident reports, and centralized logs to understand how the application has performed in production. Ideally, we're targeting 99.9% uptime or higher, alongside fast response times and a good customer experience.

If historical uptime data isn't available, I would look for other sources, such as monitoring data from the infrastructure provider. If centralized logging isn't in place, I would want to understand how incidents have been tracked and how difficult it would be to identify problems after acquisition.

An application being online isn't enough if customers constantly experience slow load times or errors. Both availability and performance matter because reliability issues can hurt customer satisfaction and ultimately lead to churn.

3. Understand the Cost of Technical Debt

Technical debt is difficult to assess because not every shortcut is necessarily a problem. Particularly with smaller teams and solo developers, some compromises are inevitable when trying to ship features and meet deadlines.

I would use AI to help identify unsupported dependencies, frameworks, and libraries, but I wouldn't judge an application simply because it uses older technology. My bigger concern is whether the code has become fragile and difficult to maintain.

I want to understand whether adding a feature or changing one part of the application is likely to break something else. A good test suite and CI/CD pipeline help reduce that risk by making it easier to catch regressions before they reach production. Documentation also matters because I need to understand how the system works and how to make changes safely.

The goal is to identify what technical debt we'll inherit, what needs to be addressed upfront, and what can reasonably be left alone. Some applications might require initial cleanup but become easy to maintain afterward. Others might require ongoing work just to keep them functional.

I want to understand that distinction before acquisition so I can estimate the work involved and determine whether the application is a good fit for our portfolio.

4. Look Beyond Revenue at Infrastructure

I want to understand all the infrastructure the application depends on, where everything is hosted, and how much it costs. This includes the application servers, database, third-party APIs, and any other paid services.

We have infrastructure we're comfortable working with, such as DigitalOcean and self-hosted droplets with PostgreSQL, but I'm not looking to force every acquisition onto the same stack. I want to understand what the application currently uses, whether those choices make sense, and whether there are opportunities to reduce costs after acquisition.

I'll also look at how deployments and updates work. Are they automated through CI/CD, or does releasing an update require several manual steps? Are backups running, and has restoring them actually been tested?

Beyond costs, I want to make sure the infrastructure is reliable and can handle future growth without requiring significant engineering work. Infrastructure expenses directly affect profitability, so we need to understand whether those costs are reasonable for the business's MRR.

5. Consider What Happens After the Acquisition

This is one of the most important parts of my evaluation. Since we're managing a portfolio of companies, I want to minimize the time spent maintaining each application.

My target is three hours or less of development maintenance per week once an application is in maintenance mode, excluding new feature development and planned technical-debt cleanup.

To make that realistic, I want centralized logging, monitoring dashboards, and uptime reporting in place so I can quickly see whether the application is healthy and investigate issues when they arise. I don't want to spend hours manually checking services or trying to figure out why something stopped working.

I also want to ensure that deployments are straightforward, backups are tested, and the infrastructure is reliable and easy to understand. Fast load times and consistent uptime are important for keeping existing customers satisfied and protecting the MRR we're acquiring.

Before handoff, I want to understand what ongoing maintenance will actually involve. If the application has known issues that need fixing, I want those documented along with the work required to address them. I also need enough documentation to take over development and operations without relying on the previous owner to explain how everything works.

The goal is to establish a system that can continue running reliably without requiring constant developer intervention. If an application needs significant maintenance every week just to keep it alive, that's something I want to identify before the acquisition rather than discover afterward.

Technical Due Diligence Is About Long-Term Ownership

My goal isn't to find reasons to walk away from an acquisition or nitpick every decision made by the original developer. It's to understand what I'm taking ownership of and what it will realistically take to operate the business afterward.

I want to know how the codebase works, what technical debt needs attention, how much the infrastructure costs, and whether the application can be maintained without significant ongoing development work.

If there are problems, that's not necessarily a reason to reject the deal. What matters is understanding those problems beforehand, knowing what needs to be fixed, and determining whether the application can reach a point where maintenance is manageable.

Ultimately, I want to acquire software that I can understand, maintain, and keep running reliably without it becoming a constant drain on development time. The better we understand the technical side before acquisition, the easier it is to plan the handoff, protect existing customers and revenue, and operate the business sustainably over the long term.