3 signs your tech stack needs an audit (before it blows up in production)

It's 3 AM. Your phone rings. PagerDuty. Again. Production is down. This is the fourth time this month. You know something is wrong, but you don't know exactly what or where to start fixing it.

If that scene sounds familiar, you're not alone. And it's probably not "bad luck" or "an isolated bug." It's the symptom of something deeper: critical technical debt accumulated over months or years.

The good news: there are clear signs that precede a technical crisis. If you catch them in time, you can prevent it with a 2-3 week technical audit instead of 6 months of emergency refactoring.

This is the complete self-diagnosis guide, based on 31 technical audits we've done at onext at Series A-C startups over the last 2 years.

Sign #1: production incidents multiply exponentially

What to watch:

Measure the number of critical production incidents (downtime >5 min, service degradation, data loss, security breach) over the last 6 months:

• Green: 0-2 incidents/month with a stable or decreasing trend
• Yellow: 3-5 incidents/month or a slight upward trend
• Red: >6 incidents/month or >50% growth in the last 3 months

Critical red flag: If your incidents doubled or tripled in the last 6 months without you doubling features or traffic, you have a structural problem, not a temporary one.

Why it happens (root causes):

When incidents increase exponentially, it's usually due to a combination of these 4 factors:

1. System complexity grew faster than observability

• You went from a monolith to microservices without implementing distributed tracing
• You added queues, workers, cron jobs, lambdas… but monitoring is still "CloudWatch default"
• You don't have end-to-end visibility of critical requests (e.g. from checkout to payment to fulfillment)

Result: When something fails, it takes you hours to identify WHERE it failed, because you're debugging "blind."

2. Testing coverage dropped while the codebase grew

• Coverage was 70% a year ago, now it's 45% (new code is written without tests)
• Tests are flaky (1 in every 3 runs fails for reasons unrelated to the code)
• E2E tests are nonexistent or take 45 minutes (nobody runs them before merge)

Result: Bugs that tests should catch in CI reach production because "we don't have time to write tests."

3. The deploy process didn't evolve with the product

• You still do manual deploys even though the app grew 10x in complexity
• You don't have automatic rollback (if a deploy breaks production, it takes you 20-60 min to revert)
• There's no staging environment that faithfully replicates production

Result: Every deploy is Russian roulette. Sometimes it works, sometimes it doesn't. Nobody knows why.

4. Technical debt reached critical mass

• Legacy code 3+ years old that nobody understands but "works" (until it doesn't)
• Critical dependencies out of date because "migrating is risky"
• An architecture that worked for 100 users/day now handles 10,000 users/day (without refactoring)

Result: The system is at its limit. Any small change has unexpected effects (cascading failures).

Real case: a B2B SaaS that went from 2 to 18 incidents/month in 5 months

Context:

• Series B startup, €4M ARR, 22 developers
• Stack: Node.js monolith + PostgreSQL + Redis + AWS EC2
• Product: an analytics platform for eCommerce

Incident evolution:

• January 2024: 2 incidents
• February: 3 incidents
• March: 5 incidents
• April: 9 incidents
• May: 14 incidents
• June: 18 incidents (PagerDuty alerts at 2 AM became routine)

Root cause discovered in a 3-day audit:

• Database without proper indexing (queries went from 50ms to 8 seconds in 6 months)
• Memory leak in the analytics-processing worker (it filled RAM every 36 hours → crash)
• Redis configured with the wrong eviction policy (critical data was deleted under pressure)
• Unstructured logs (impossible to run useful queries for debugging)

Solution implemented (4 weeks):

• Database optimization: we added indexes on N+1 queries, going from 8s to 120ms
• We fixed the memory leak (it was 1 line of code: an EventEmitter without cleanup)
• We reconfigured Redis + added eviction monitoring
• We implemented structured logging with Datadog

Result: From 18 incidents/month to 1-2 incidents/month over the following 3 months.

Lesson: The incidents weren't "bad luck." They were symptoms of 4 structural problems that a 3-day audit identified and 4 weeks of work resolved.

Sign #2: onboarding time for new developers increased 3-4x

What to watch:

Measure how long it takes a new developer (mid-level or senior) to become productive (make their first useful PR without constant supervision):

• Green: 1-2 weeks to first productive PR
• Yellow: 3-4 weeks
• Red: >5 weeks or "they never really become autonomous"

Critical red flag: If 2 years ago onboarding took 1 week and now it takes 4-6 weeks, your architecture became incomprehensible. That is NOT normal.

Why it happens:

1. Nonexistent or outdated documentation

• The README says "run npm install" but you actually need 8 additional undocumented steps
• The architecture documented 2 years ago no longer reflects the current system
• Setting up the local environment takes 2 days with help from 3 developers (it should take 2 hours without help)

2. Accidental vs essential complexity

• To add a field to a form, you have to touch 12 files across 5 different folders
• Inconsistent patterns: each feature was implemented with a different approach
• "Clever" abstractions that made the code harder to understand, not easier

3. Tribal knowledge (knowledge in heads, not in code/docs)

• "To understand how X works, you have to ask Juan" (and what if Juan leaves?)
• Code with no comments, cryptic variable names, 400-line functions
• Critical configurations that live in Slack threads from 8 months ago

Self-diagnosis: the "ghost developer" test

Imagine you hire a remote developer you've never met in person. You give them access to the repo and ask them to:

1. Spin up the project locally
2. Run the tests
3. Make a simple change (add a field to a table + expose it in the API)
4. Deploy to staging

Can they do all of that just by reading the existing documentation, without asking anyone?

• Yes, in <4 hours: Your codebase is well structured and documented ✅
• Yes, but it takes 2 days: You have significant documentation debt ⚠️
• No, they need constant help: You have critical tribal knowledge 🚨

"I hired a senior developer with 8 years of Node.js experience. It took them 6 weeks to make their first PR without supervision. It wasn't a skills problem, it was that our codebase had become so complex and poorly documented that even seniors got lost."

— CTO of a Healthtech startup (Madrid), 16 developers

Sign #3: deploy time increased while features slowed down

What to watch:

Measure two key metrics over the last 12 months:

Metric 1: Deploy time (commit → production):

• Green: <30 minutes, stable or decreasing
• Yellow: 30-120 minutes
• Red: >2 hours or increased >100% in the last year

Metric 2: Feature lead time (spec → production):

• Green: Small features in 1-3 days, medium ones in 1-2 weeks
• Yellow: Small features in 1 week, medium ones in 3-4 weeks
• Red: Small features in >2 weeks, medium ones in >6 weeks

Critical red flag: If both metrics worsened simultaneously, your architecture and/or processes became a critical bottleneck.

Why it happens:

1. Monolithic architecture without modularization

• A deploy requires deploying the ENTIRE monolith even if you change 1 line
• Build time increased from 3 min to 18 min because the bundle grew without tree-shaking
• Tests run sequentially in 45 minutes (without parallelization)

2. High coupling between components

• To add a feature in module A, you have to modify modules B, C, and D
• PRs that used to touch 1 file now touch 15 files
• Regression risk increased → more manual testing → more time

3. Infrastructure didn't scale with the product

• Database queries became slow (without index optimization)
• CI/CD still runs on basic runners (without horizontal scaling)
• The staging environment takes 20 min to spin up because it's poorly configured

Impact calculator: how much does a slow deploy cost you?

If your deploy takes 2 hours instead of 20 minutes:

• Time lost per deploy: 1h 40min extra x 10 deploys/month = 16.6 hours/month
• Developers affected: 2-3 people blocked during that time
• Opportunity cost: 16.6 hours x 2.5 developers x €65/hour = €2,700/month = €32,400/year

And that's without counting:

• Context switching (developers switch tasks during a long deploy, losing focus)
• Fear of deployment (if a deploy takes 2 hours, you deploy less → features take longer to reach clients)
• Reduced iteration speed (if A/B testing requires 2 deploys, it takes you 4 hours instead of 40 min)

ROI of optimizing the deploy: Investing 3 weeks in optimizing CI/CD (€12k in developer time) saves you €32k/year. Break-even: 4.5 months. Year 1 ROI: 167%.

Complete self-diagnosis checklist

Use this checklist to assess whether you need an urgent technical audit:

Observability & Monitoring (10 points):

• ❌ Production incidents increased >50% in the last 6 months
• ❌ MTTR (time to resolve an incident) is >2 hours
• ❌ We don't have distributed tracing (in an architecture with >3 services)
• ❌ Logs aren't structured (we can't run useful queries)
• ❌ We don't have SLI-based alerting (only generic CPU/RAM alerts)

Code Quality & Testing (10 points):

• ❌ Test coverage is <60% or dropped >15% in the last year
• ❌ Tests are flaky (>10% false negatives)
• ❌ We don't have E2E tests for critical user journeys
• ❌ Code reviews take >2 days (due to code complexity or lack of tests)
• ❌ Onboarding new developers takes >3 weeks

Architecture & Performance (10 points):

• ❌ Database queries take >500ms at p95
• ❌ Deploy time increased >100% in the last year
• ❌ We can't deploy without downtime
• ❌ Rollback takes >30 minutes
• ❌ Small features take >1 week to reach production

Documentation & Knowledge (10 points):

• ❌ Setting up the local environment takes >4 hours
• ❌ Architecture documentation is >6 months out of date
• ❌ >50% of critical knowledge lives in the heads of 1-2 people
• ❌ There are no runbooks for common incidents
• ❌ Critical technical decisions aren't documented (only in Slack/memory)

Interpreting the results:

• 0-5 ❌: Healthy stack, only small incremental improvements
• 6-12 ❌: Moderate technical debt, plan an audit in the next 3 months
• 13-20 ❌: Significant technical debt, audit recommended in the next 4-6 weeks
• >20 ❌: Critical technical debt, urgent audit (risk of imminent crisis)

What a technical audit does (and what it does NOT do)

A well-done technical audit is NOT "a consultant who criticizes your code for 2 weeks and hands you an 80-page PDF that nobody reads."

An effective audit is:

1. A 2-3 day diagnosis (not weeks)
   • Review of the current architecture (not just code, but also infra and processes)
   • Identification of critical bottlenecks (the top 5 problems that cause 80% of the pain)
   • Interviews with the team (developers, devops, product) to understand pain points
2. A prioritized remediation roadmap (not a generic list of "best practices")
   • Quick wins (2-4 weeks, high impact, low effort)
   • Structural improvements (2-3 months, high impact, medium effort)
   • Long refactorings (6+ months, necessary but can wait)
3. ROI estimation per initiative
   • How much time/money you'll save
   • How long it will take to implement
   • What the break-even is
4. Clear ownership
   • What your internal team can do
   • What requires external expertise
   • What's critical vs nice-to-have

An effective audit is NOT:

• ❌ A complete rewrite of your application (99% of the time it's not necessary)
• ❌ Migrating to the latest trendy technology because "it's better"
• ❌ A generic report copied from other projects
• ❌ A 6-month consultancy that leaves you dependent

The expected result of a well-done audit: In 2-3 days, you know exactly what's wrong, why, and what the 12-week plan is to fix it (with quantified ROI for each initiative).

Do you recognize any of these 3 signs in your startup?

If you answered "yes" to any of these 3 signs, don't wait for the situation to get worse:

• Sign #1: Production incidents multiplied in the last 6 months
• Sign #2: Developer onboarding now takes 3-4x longer than 1-2 years ago
• Sign #3: Deploy time and feature lead time increased simultaneously

These signs do NOT fix themselves. On the contrary: technical debt grows exponentially if you don't tackle it in a structured way.

At onext we do 2-3 day technical audits for Series A-C startups. We identify the 5 critical problems that cause 80% of the pain and design a remediation roadmap prioritized by ROI.

No unnecessary rewrites. No technology migrations just because. No 80-page PDFs that nobody reads.

Just a clear diagnosis, an actionable plan, and quantified ROI.