Son las 3 AM. Tu móvil suena. PagerDuty. Otra vez. Producción caída. Esta es la cuarta vez este mes. Sabes que algo está mal, pero no sabes exactamente qué ni por dónde empezar a arreglarlo.
Si esa escena te suena familiar, no estás solo. Y probablemente, no es "mala suerte" ni "un bug aislado". Es el síntoma de algo más profundo: deuda técnica crítica acumulada durante meses o años.
La buena noticia: hay señales claras que preceden a una crisis técnica. Si las detectás a tiempo, podés prevenirla con una auditoría técnica de 2-3 semanas en lugar de 6 meses de refactoring de emergencia.
Esta es la guía completa de autodiagnóstico basada en 31 auditorías técnicas que hemos hecho en onext en startups Serie A-C durante los últimos 2 años.
Señal #1: Los incidentes en producción se multiplican exponencialmente
Qué observar:
Medí el número de incidentes críticos en producción (downtime >5 min, degradación de servicio, data loss, security breach) en los últimos 6 meses:
- Verde: 0-2 incidentes/mes con tendencia estable o decreciente
- Amarillo: 3-5 incidentes/mes o tendencia creciente leve
- Rojo: >6 incidentes/mes o crecimiento >50% en últimos 3 meses
Red flag crítica: Si tus incidentes se duplicaron o triplicaron en los últimos 6 meses sin que hayas duplicado features o tráfico, tenés un problema estructural, no coyuntural.
Por qué sucede (causas raíz):
Cuando incidentes aumentan exponencialmente, generalmente es por una combinación de estos 4 factores:
1. Complejidad del sistema creció más rápido que la observability
- Pasaste de monolito a microservicios sin implementar tracing distribuido
- Agregaste colas, workers, cron jobs, lambdas… pero el monitoreo sigue siendo "CloudWatch default"
- No tenés visibilidad end-to-end de requests críticos (ej: desde checkout a payment a fulfillment)
Resultado: Cuando algo falla, tardás horas en identificar DÓNDE falló, porque estás debuggeando "a ciegas".
2. Testing coverage bajó mientras codebase creció
- Coverage era 70% hace un año, ahora es 45% (nuevo código se escribe sin tests)
- Tests son flaky (1 de cada 3 runs falla por razones no relacionadas con el código)
- Tests e2e son inexistentes o toman 45 minutos (nadie los corre antes de merge)
Resultado: Bugs que tests deberían detectar en CI llegan a producción porque "no tenemos tiempo de escribir tests".
3. Deploy process no evolucionó con el producto
- Seguís haciendo deploys manuales aunque la app creció 10x en complejidad
- No tenés rollback automático (si deploy rompe producción, tardás 20-60 min en revertir)
- No hay staging environment que replique producción fielmente
Resultado: Cada deploy es una ruleta rusa. A veces funciona, a veces no. Nadie sabe por qué.
4. Deuda técnica alcanzó masa crítica
- Código legacy de 3+ años que nadie entiende pero "funciona" (hasta que no funciona)
- Dependencias críticas desactualizadas porque "migrar es riesgoso"
- Arquitectura que funcionaba para 100 users/día ahora maneja 10,000 users/día (sin refactoring)
Resultado: El sistema está al límite. Cualquier cambio pequeño tiene efectos inesperados (cascading failures).
Caso real: SaaS B2B que pasó de 2 a 18 incidentes/mes en 5 meses
Contexto:
- Startup Serie B, €4M ARR, 22 developers
- Stack: Node.js monolito + PostgreSQL + Redis + AWS EC2
- Producto: Plataforma de analytics para eCommerce
Evolución de incidentes:
- Enero 2024: 2 incidentes
- Febrero: 3 incidentes
- Marzo: 5 incidentes
- Abril: 9 incidentes
- Mayo: 14 incidentes
- Junio: 18 incidentes (PagerDuty alertas a las 2 AM se volvieron rutina)
Causa raíz descubierta en auditoría de 3 días:
- Database sin indexación adecuada (queries aumentaron de 50ms a 8 segundos en 6 meses)
- Memoria leak en worker de procesamiento de analytics (llenaba RAM cada 36 horas → crash)
- Redis configurado con eviction policy incorrecta (datos críticos se borraban bajo presión)
- Logs no estructurados (imposible hacer queries útiles para debugging)
Solución implementada (4 semanas):
- Database optimization: agregamos índices en queries N+1, pasamos de 8s a 120ms
- Arreglamos memory leak (fue 1 línea de código: EventEmitter sin cleanup)
- Reconfiguramos Redis + agregamos monitoring de evictions
- Implementamos structured logging con Datadog
Resultado: De 18 incidentes/mes a 1-2 incidentes/mes en los siguientes 3 meses.
Señal #2: El tiempo de onboarding de nuevos developers aumentó 3-4x
Qué observar:
Medí cuánto tarda un developer nuevo (mid-level o senior) en ser productivo (hacer su primer PR útil sin supervisión constante):
- Verde: 1-2 semanas para primer PR productivo
- Amarillo: 3-4 semanas
- Rojo: >5 semanas o "nunca llegan a ser realmente autónomos"
Red flag crítica: Si hace 2 años onboarding tardaba 1 semana y ahora tarda 4-6 semanas, tu arquitectura se volvió incomprensible. Eso NO es normal.
Por qué sucede:
1. Documentación inexistente o desactualizada
- README dice "run npm install" pero en realidad necesitás 8 pasos adicionales no documentados
- Arquitectura documentada hace 2 años ya no refleja el sistema actual
- Setup de local environment tarda 2 días con ayuda de 3 developers (debería tardar 2 horas sin ayuda)
2. Complejidad accidental vs esencial
- Para agregar un campo a un formulario, tenés que tocar 12 archivos en 5 carpetas diferentes
- Patrones inconsistentes: cada feature fue implementada con un approach diferente
- Abstracciones "inteligentes" que hicieron el código más difícil de entender, no más fácil
3. Tribal knowledge (conocimiento en cabezas, no en código/docs)
- "Para entender cómo funciona X, tenés que preguntarle a Juan" (¿y si Juan se va?)
- Código sin comments, nombres de variables crípticos, funciones de 400 líneas
- Configuraciones críticas que viven en Slack threads de hace 8 meses
Autodiagnóstico: El test del "developer fantasma"
Imaginá que contratas un developer remoto que nunca conociste en persona. Le das acceso al repo y le pedís:
- Levantar el proyecto en local
- Correr los tests
- Hacer un cambio simple (agregar un campo a una tabla + exponerlo en API)
- Deployar a staging
¿Puede hacer todo eso solo leyendo documentación existente, sin preguntar a nadie?
- Sí, en <4 horas: Tu codebase está bien estructurado y documentado ✅
- Sí, pero tarda 2 días: Tenés deuda de documentación importante ⚠️
- No, necesita ayuda constante: Tenés tribal knowledge crítico 🚨
"Contraté a un senior developer con 8 años de experiencia en Node.js. Tardó 6 semanas en hacer su primer PR sin supervisión. No era un problema de skills, era que nuestro codebase se había vuelto tan complejo y poco documentado que incluso seniors se perdían."
— CTO de Healthtech startup (Madrid), 16 developers
Señal #3: El tiempo de deploy aumentó mientras features se ralentizaron
Qué observar:
Medí dos métricas clave en los últimos 12 meses:
Métrica 1: Tiempo de deploy (commit → producción):
- Verde: <30 minutos, estable o decreciente
- Amarillo: 30-120 minutos
- Rojo: >2 horas o aumentó >100% en último año
Métrica 2: Lead time de features (spec → producción):
- Verde: Features pequeñas en 1-3 días, medianas en 1-2 semanas
- Amarillo: Features pequeñas en 1 semana, medianas en 3-4 semanas
- Rojo: Features pequeñas en >2 semanas, medianas en >6 semanas
Red flag crítica: Si ambas métricas empeoraron simultáneamente, tu arquitectura y/o procesos se volvieron un cuello de botella crítico.
Por qué sucede:
1. Arquitectura monolítica sin modularización
- Deploy requiere deployar TODO el monolito aunque cambies 1 línea
- Build time aumentó de 3 min a 18 min porque el bundle creció sin tree-shaking
- Tests corren secuencialmente en 45 minutos (sin paralelización)
2. Coupling alto entre componentes
- Para agregar un feature en módulo A, tenés que modificar módulos B, C, y D
- PRs que tocaban 1 archivo ahora tocan 15 archivos
- Risk de regression aumentó → más testing manual → más tiempo
3. Infraestructura no escaló con el producto
- Database queries se volvieron lentas (sin optimización de índices)
- CI/CD sigue corriendo en runners básicos (sin scaling horizontal)
- Staging environment tarda 20 min en levantar porque está mal configurado
Calculadora de impacto: ¿Cuánto te cuesta el deploy lento?
Si tu deploy tarda 2 horas en lugar de 20 minutos:
- Tiempo perdido por deploy: 1h 40min extra x 10 deploys/mes = 16.6 horas/mes
- Developers afectados: 2-3 personas bloqueadas durante ese tiempo
- Costo de oportunidad: 16.6 horas x 2.5 developers x €65/hora = €2,700/mes = €32,400/año
Y eso sin contar:
- Context switching (developers cambian de tarea durante deploy largo, pierden focus)
- Fear of deployment (si deploy tarda 2 horas, deployás menos → features tardan más en llegar a clientes)
- Reduced iteration speed (si A/B testing requiere 2 deploys, tardás 4 horas en lugar de 40 min)
Checklist de autodiagnóstico completo
Usa esta checklist para evaluar si necesitás una auditoría técnica urgente:
Observability & Monitoring (10 puntos):
- ❌ Incidentes en producción aumentaron >50% en últimos 6 meses
- ❌ MTTR (tiempo hasta resolver incidente) es >2 horas
- ❌ No tenemos tracing distribuido (en arquitectura con >3 servicios)
- ❌ Logs no están estructurados (no podemos hacer queries útiles)
- ❌ No tenemos alerting basado en SLIs (solo alertas genéricas de CPU/RAM)
Code Quality & Testing (10 puntos):
- ❌ Coverage de tests es <60% o bajó >15% en último año
- ❌ Tests son flaky (>10% de false negatives)
- ❌ No tenemos tests e2e para user journeys críticos
- ❌ Code reviews tardan >2 días (por complejidad de código o falta de tests)
- ❌ Onboarding de nuevos developers tarda >3 semanas
Architecture & Performance (10 puntos):
- ❌ Queries a database tardan >500ms en p95
- ❌ Tiempo de deploy aumentó >100% en último año
- ❌ No podemos deployar sin downtime
- ❌ Rollback tarda >30 minutos
- ❌ Features pequeñas tardan >1 semana en llegar a producción
Documentation & Knowledge (10 puntos):
- ❌ Setup de local environment tarda >4 horas
- ❌ Documentación de arquitectura tiene >6 meses de desactualización
- ❌ >50% del conocimiento crítico está en cabezas de 1-2 personas
- ❌ No hay runbooks para incidentes comunes
- ❌ Decisiones técnicas críticas no están documentadas (solo en Slack/memoria)
Interpretación de resultados:
- 0-5 ❌: Stack saludable, solo pequeñas mejoras incrementales
- 6-12 ❌: Deuda técnica moderada, planificar auditoría en próximos 3 meses
- 13-20 ❌: Deuda técnica significativa, auditoría recomendada en próximas 4-6 semanas
- >20 ❌: Deuda técnica crítica, auditoría urgente (riesgo de crisis inminente)
Qué hace una auditoría técnica (y qué NO hace)
Una auditoría técnica bien hecha NO es "un consultor que critica tu código durante 2 semanas y te entrega un PDF de 80 páginas que nadie lee".
Una auditoría efectiva es:
- Diagnóstico de 2-3 días (no semanas)
- Revisión de arquitectura actual (no solo código, también infra y procesos)
- Identificación de bottlenecks críticos (top 5 problemas que causan el 80% del dolor)
- Entrevistas con equipo (developers, devops, product) para entender pain points
- Roadmap priorizado de remediación (no lista genérica de "mejores prácticas")
- Quick wins (2-4 semanas, alto impacto, bajo esfuerzo)
- Mejoras estructurales (2-3 meses, alto impacto, medio esfuerzo)
- Refactorings largos (6+ meses, necesarios pero pueden esperar)
- Estimación de ROI por iniciativa
- Cuánto tiempo/dinero ahorrarás
- Cuánto tardará en implementarse
- Cuál es el break-even
- Ownership claro
- Qué puede hacer tu equipo interno
- Qué requiere expertise externo
- Qué es crítico vs nice-to-have
Una auditoría efectiva NO es:
- ❌ Una rewrite completa de tu aplicación (99% de las veces no es necesario)
- ❌ Migrar a la última tecnología de moda porque "es mejor"
- ❌ Un informe genérico copiado de otros proyectos
- ❌ Una consultoría de 6 meses que te deja dependiente
Resultado esperado de auditoría bien hecha: En 2-3 días, sabés exactamente qué está mal, por qué, y cuál es el plan de 12 semanas para arreglarlo (con ROI cuantificado para cada iniciativa).
¿Reconocés alguna de estas 3 señales en tu startup?
Si respondiste "sí" a alguna de estas 3 señales, no esperés a que la situación empeore:
- Señal #1: Incidentes en producción se multiplicaron en últimos 6 meses
- Señal #2: Onboarding de developers ahora tarda 3-4x más que hace 1-2 años
- Señal #3: Deploy time y feature lead time aumentaron simultáneamente
Estas señales NO se arreglan solas. Al contrario: la deuda técnica crece exponencialmente si no la atacás de manera estructurada.
En onext hacemos auditorías técnicas de 2-3 días para startups Serie A-C. Identificamos los 5 problemas críticos que causan el 80% del dolor y diseñamos un roadmap de remediación priorizado por ROI.
Sin rewrites innecesarios. Sin migraciones de tecnología porque sí. Sin PDFs de 80 páginas que nadie lee.
Solo un diagnóstico claro, un plan accionable, y ROI cuantificado.