Assessing Code Quality in a SaaS Acquisition: What Actually Matters

Code quality assessment is the part of due diligence that most non-technical buyers skip entirely and most technical buyers overanalyze. The truth is somewhere in between.

What actually matters in an acquisition context. You're not evaluating code for a job interview. You're trying to answer three questions: Can I maintain this? Can I improve this? Are there hidden risks?

Architecture over style. A well-structured application with inconsistent formatting is far better than a beautifully written monolith. Look at the project structure first. Is there clear separation of concerns? Are database queries separated from business logic? Is the routing logical?

Dependencies are the real risk. A SaaS with 200 npm dependencies has 200 potential breaking changes, security vulnerabilities, and license conflicts. Run a dependency audit. Focus on: outdated major versions (more than 2 majors behind), known CVEs (especially in authentication or data handling libraries), and abandoned packages (no updates in 12+ months).

Test coverage is a proxy, not a goal. Zero tests is a yellow flag. It means every change carries risk. 80%+ coverage is great but rare in micro-SaaS. What matters most is whether the critical paths are tested: authentication, payment processing, and core feature logic.

The bus factor. How many people understand this codebase? Check git history. If one person wrote 95% of the code and that person is the seller who's leaving, you need to factor in significant ramp-up time. If there's good documentation and clean code, the bus factor matters less.

Framework and language choice. This is less about what's "best" and more about what you can work with. If the SaaS is built in a language you don't know, factor in hiring costs or learning time. The most commonly acquired SaaS products are built in JavaScript/TypeScript (Next.js, Node), Python (Django, Flask), Ruby (Rails), and PHP (Laravel).

Infrastructure complexity. A SaaS running on a single managed platform (Heroku, Vercel, Railway) is operationally simple. One running across 12 AWS services with custom Terraform configurations is operationally complex. Factor operational complexity into your post-acquisition time budget.

What you can safely deprioritize. Code style and formatting (fixable with tools in an afternoon). Minor UI inconsistencies. Performance optimization (unless users are complaining). Documentation completeness (you'll need to rewrite it anyway as you learn the system).

Our approach. At AcquiCheck, we run automated scans for dependencies, vulnerabilities, and license compliance, then do a manual architecture review. The combination catches structural issues that automation misses while keeping the process fast enough for micro-acquisition timelines.