Red Flags in a Software Codebase — What Technical Due Diligence Reveals

Technical due diligence reveals codebase health through eight indicators: test coverage below 20% (the team ships without verification), no CI/CD pipeline (deployments are manual and error-prone), hardcoded credentials or API keys in source code (security incident waiting to happen), no database migrations (schema changes are applied manually in production), single points of failure in the architecture (one server crash takes everything down), no error logging or monitoring (problems are discovered by users, not engineers), god objects or files over 2,000 lines (the code has grown without design), and no documentation of business logic (knowledge exists only in one developer's head).

These red flags surface consistently across acquisition assessments, vendor audits, and founder-commissioned code reviews. Each one represents compounding technical debt — the longer it exists, the more expensive it becomes to fix.

The eight indicators split into three categories: delivery process failures (no tests, no CI/CD), security and data integrity risks (hardcoded credentials, no migrations), and architectural decay (single points of failure, no monitoring, god objects, undocumented logic). The severity ranges from a few days of remediation to deal-breaking structural problems.

What are the biggest red flags in a software codebase?

The table separates survivable problems from deal-breakers. Low test coverage is expensive to fix but rarely fatal — the code still runs. Hardcoded credentials in a public repository may have already been exploited. The distinction matters when you are deciding whether to renegotiate the price or walk away.

What does low test coverage tell you about a codebase?

Test coverage below 20% means the engineering team ships code without automated verification. Every deployment is a manual bet that nothing broke. In codebases we have assessed, low test coverage correlates with three other problems: longer release cycles because teams are afraid to deploy, higher defect rates in production, and a pattern of hotfix commits that outnumber planned releases.

The fix cost depends on codebase size. For a 50,000-line application, reaching 60% coverage typically requires 3–6 months of dedicated effort — writing tests for existing code is slower than writing tests alongside new code. The question for due diligence is not whether this can be fixed but who is going to fix it and what that costs in the first 12 months post-acquisition.

Zero test coverage is different from low coverage. Zero means the team never established the practice. Low coverage — 5% to 15% — means they started and stopped, which often indicates management pressure to skip testing in favour of shipping features. Both are fixable. Neither is free.

Why is no CI/CD pipeline a red flag?

No CI/CD pipeline means deployments happen manually — an engineer runs commands on a production server, copies files, or executes database scripts by hand. Manual deployments introduce three risks: human error during the deployment itself, no rollback path when something goes wrong, and no audit trail of what was deployed and when.

We have seen production environments where the deployment process existed only in one developer's head. That developer's departure would mean no one at the company knew how to ship code to production. This is not hypothetical — it is the second most common finding in technical due diligence after inadequate test coverage.

The fix is straightforward: a basic CI/CD pipeline using GitHub Actions, GitLab CI, or equivalent takes 1–3 days to set up for a standard application. The severity of this red flag is not about fix cost — it is about what it reveals. A team that deploys manually in 2026 has not adopted basic engineering practices that have been standard for over a decade.

In due diligence, the CI/CD question is binary — it exists or it does not. If it exists, check what it runs: a pipeline that only builds the code without running tests or security scans provides deployment automation but not quality gates. A complete pipeline runs tests, checks for known vulnerabilities, and deploys to a staging environment before production. The gap between these two tells you how seriously the team treats production stability.

What security red flags appear in code reviews?

Hardcoded credentials — database passwords, API keys, third-party service tokens stored directly in source code — are the most dangerous red flag in any codebase review. If the repository has ever been public, or if any developer's laptop has been compromised, those credentials are exposed.

The check is simple: search the repository history for strings matching API key patterns, connection strings, or password assignments. Tools like git-secrets or TruffleHog catch most instances. The critical point is searching the entire git history, not just the current codebase — credentials removed in a later commit still exist in the repository's history unless it has been rewritten.

Other security red flags that surface during code reviews include SQL queries built by string concatenation, user input rendered without sanitisation, authentication tokens stored in local storage instead of HTTP-only cookies, and no rate limiting on authentication endpoints. Each is individually fixable. Finding three or more in the same codebase indicates a team that did not include security review in their development process.

How do you assess code quality during due diligence?

Code quality assessment during due diligence goes beyond security. It evaluates whether the codebase can be maintained, extended, and scaled by a team that did not write it.

No database migrations — schema changes applied directly to production databases instead of through versioned migration files — means there is no reliable way to reproduce the database structure. If you need to set up a new environment, restore from backup, or understand what changed between versions, you are guessing. This red flag appears in roughly 40% of the codebases we assess for clients evaluating acquisitions or prior vendor work. The fix itself is not expensive — 2–4 weeks to reconstruct migration history for a typical application — but the risk during that reconstruction is high, because undocumented schema dependencies may surface only when something breaks.

God objects — classes or files exceeding 2,000 lines that handle multiple unrelated responsibilities — indicate the code grew without architectural planning. A 3,000-line ApplicationController or a Utils.js file that handles authentication, email sending, and payment processing is code that no new developer can understand without weeks of archaeology. The fix requires systematic refactoring, typically 2–4 months for a mid-sized application.

No documentation of business logic is the red flag that creates the most post-acquisition risk. When the rules governing pricing calculations, approval workflows, or compliance checks exist only in the code — with no written specification — every change becomes an exercise in reverse engineering. The business logic documentation gap means you are acquiring code that a new team cannot safely modify without risking breaking rules they do not know exist.

What codebase red flags should kill an acquisition?

Not every red flag is a deal-breaker. Low test coverage, missing CI/CD, and god objects are all fixable with time and budget. Three red flags should make you reconsider the acquisition entirely.

Single points of failure in the architecture — one server, one database, no redundancy — mean a single hardware failure or traffic spike takes the entire application offline. If the business depends on uptime for its SaaS product, eCommerce platform, or operations system, this is not a deferred maintenance item. It is an active business risk that exists from day one of ownership.

No error logging or monitoring means problems are discovered by users, not engineers. When the application throws an error, no one knows until a customer reports it. In production systems we have audited, the absence of monitoring typically means the team has no data on error frequency, response times, or system health. You are buying a system and hoping it works — you have no evidence that it does.

The combination of multiple red flags is worse than any single one. A codebase with low test coverage AND no CI/CD AND no monitoring is a system where bugs are introduced without detection, deployed without safeguards, and discovered only when they cause visible damage. That combination represents months of remediation work before you can safely build new features.

We run technical due diligence for companies evaluating acquisitions and for founders assessing what their previous vendor delivered. The codebase tells the truth the demo does not. A working login screen says nothing about what is behind it — the test suite, the deployment pipeline, the error handling, the architecture decisions that determine whether this system can grow or needs to be rebuilt.