How to do SaaS technical due diligence

Buying a SaaS? Now Let’s Make Sure It Won’t Explode

Most first-time SaaS buyers think they’re buying a cash machine. Passive income, high margins, sweet deal. Then six months later, they’re buried in support tickets, AWS bills, and code they don’t understand.

HoldCos with multiple SaaS properties? You already know the game: Some of these deals are gold, but a lot are landmines disguised as software.

Buying a SaaS can be a great investment, that's not the issue. It’s the lack of real technical due diligence in this price range. Most diligence in the sub-$5M SaaS market is founder-led storytelling and a GitHub handoff. That’s why we built TechFax — to automate the real technical checks before you wire the money. Downside protection at its finest.

Technical due diligence is about ensuring that you're buying a codebase with minimal security risks, few compliance issues, and good code quality. While you can't see the software development process from the outside, you can analyze the outputs via the website.

Step One: Automate the First Pass

In our experience, automation can tell you the quality of the SaaS in a few minutes. We know a lot with a few audits like:

• Speed: Slow sites kill conversion rates. We consolidate performance scores across every page and flag the worst offenders. (If it’s built on a bloated WordPress template with a dozen tracking scripts, you’ll know.) Speed is a great proxy for understanding technical debt. It's hard to build a fast website with lots of tech debt.

• Tech Stack: What’s powering this thing? Is it a clean, modern stack or are we running a Visual Basic .NET mess? Our system pulls all detected libraries and frameworks, then runs them through a risk assessment. Once we know the tech stack, we can start to build up an idea of what their system architecture is.

• Security: We spin up an automated penetration test, checking for known security holes. If they’re running an old PHP version with no updates, you’ll see it (hopefully) before hackers do.

• Accessibility: If they’re selling to businesses or government contracts, accessibility compliance matters. We pull a full report on whether they meet WCAG standards (or if they’re a lawsuit waiting to happen).

• CrUX (Google’s Real User Data): This tells us if real visitors are struggling with the site. If it’s been optimized only for Lighthouse scores but fails in production, we’ll catch it. This is what Google sees, so it impacts SEO too.

This all runs in minutes, not days. No waiting on a slow consultant.

Step Two: Expert CTO Review

Once the automated first pass is done, it's important to have an expert review the findings. Bring in an expert to review the findings. After reviewing the findings, it's recommended to have an expert review the actual code. This is as simple as asking for read-only GitHub access to review the code quality and architecture. If you're technical, you can probably do this yourself. If not, consider using our fractional CTO. They can dive into things like:

• Is this well-architected? Systems that are architected better will stand the test of time. You want to depreciate your asset over five years, not two right? If your software is built for scale you'll be in a much better place. If you're pouring ad dollars into getting more users it's critical that system can support the heavier load.

• How urgent is this? Our automated scans will find a lot of issues. Most sites have problems. But true expertise is knowing what to prioritize—what's a fire and what's not.

• Where is the tech debt? Every app has some amount of tech debt. In fact, there's some tech debt in the photo below and an average engineer wouldn't notice (p.s. — if you can spot the tech debt consider joining our fractional CTO network.)

Step Three: The Real Founder Test

Most founders hide from real due diligence. That’s because they don’t want you digging too deep. Getting them live on a call is critical. The right questions force them to be honest:

• “How would you rebuild this from scratch today?” → A good answer means they understand the trade-offs they made.

• “What’s the worst technical debt you never fixed?” → Every app has some tech debt. If they say “nothing,” they’re lying.

It's important to cross-check the TechFax findings with what the founder says. If the founder says "our performance is great" but Google says otherwise, trust Google. Don't buy.

Investing well means passing on a large portion of the deals you see.

The Bottom Line: If You’re Not Running These Checks, You’re Guessing

First-time SaaS buyers on Acquire.com? You need repeatable due diligence so you evaluate all deals thoroughly and consistently. HoldCos buying multiple SaaS? Every bad buy sets you back a year.

TechFax is how you stop guessing and start running technical diligence at scale. Automate the first pass. Pair with an expert. Interview the founder.

That’s how you buy SaaS the smart way. No surprises, no disasters, just signal (and profit).