After reviewing dozens of startup codebases for due diligence and consulting engagements, we've identified patterns that indicate deeper problems. Here's what to watch for.
Architecture Red Flags
1. Monolith that should be split (or vice versa)
Premature microservices are as dangerous as a monolith that's too large. Red flags include:
- 10+ microservices with a 3-person team
- A single 500K+ line monolith with no module boundaries
- Services that are tightly coupled and always deployed together
2. No clear data model
When you can't explain the core data model in 5 minutes, something is wrong. Look for: unclear entity relationships, denormalized data everywhere, no schema documentation.
3. Single points of failure
- Single database with no replicas
- All traffic through one server
- Critical services with no redundancy
- No backups or untested backups
Code Quality Issues
1. No tests at all
Zero tests isn't just a technical debt issue — it signals that changes are risky and refactoring is effectively impossible without breaking things.
2. Copy-paste everywhere
Massive code duplication means bugs get fixed in one place and not another. It also indicates a team that's moving too fast to refactor.
3. Dead code and unused dependencies
Large amounts of commented-out code, unused imports, and dependencies that aren't actually used suggest the team has lost track of what the codebase actually does.
4. Inconsistent patterns
When the same thing is done 5 different ways, new engineers can't learn patterns and every feature is a unique snowflake.
Security Vulnerabilities
- Secrets in code: API keys, passwords, tokens committed to git
- No authentication on internal APIs: Assuming network = security
- SQL injection vulnerabilities: Raw SQL with user input
- No encryption at rest: Sensitive data stored in plaintext
- Outdated dependencies: Known CVEs in production dependencies
- No rate limiting: APIs vulnerable to abuse
- Missing access controls: Any authenticated user can do anything
Process Problems
1. No code review
Code going straight to production without review is a sign of speed over quality culture. It also means knowledge is siloed.
2. Manual deployments
If deploying requires someone to SSH into servers and run commands, deployments are risky and infrequent. This slows down the entire team.
3. No monitoring or logging
If you can't answer "what happened in production yesterday", you're flying blind. Customers often know about problems before you do.
4. No documentation
When the only documentation is in someone's head, onboarding is slow and knowledge loss is inevitable.
Team and Culture Signals
- One person owns everything: Bus factor of 1 is critical risk
- High turnover: Engineers leaving quickly signals problems
- Blame culture: Fear of touching code or making changes
- Hero culture: Regular all-nighters to hit deadlines
- "We'll fix it later": Technical debt that never gets addressed
How to Address These Issues
Every codebase has some issues. The question is whether the team is aware and has a plan:
- Acknowledge honestly: Teams that hide problems are worse than teams with known problems
- Prioritize by risk: Security issues first, then stability, then code quality
- Incremental improvement: Don't plan a big rewrite — fix things as you touch them
- Add tests before changes: Cover critical paths first
- Document decisions: Create ADRs (Architecture Decision Records) for major choices
- Bring in expertise: Sometimes you need outside perspective to see blind spots