3 senyals que el teu stack tècnic necessita una auditoria (abans que exploti en producció)

Són les 3 AM. El teu mòbil sona. PagerDuty. Un altre cop. Producció caiguda. Aquesta és la quarta vegada aquest mes. Saps que alguna cosa va malament, però no saps exactament què ni per on començar a arreglar-ho.

Si aquesta escena et resulta familiar, no estàs sol. I probablement, no és "mala sort" ni "un bug aïllat". És el símptoma d'alguna cosa més profunda: deute tècnic crític acumulat durant mesos o anys.

La bona notícia: hi ha senyals clares que precedeixen una crisi tècnica. Si les detectes a temps, pots prevenir-la amb una auditoria tècnica de 2-3 setmanes en lloc de 6 mesos de refactoring d'emergència.

Aquesta és la guia completa d'autodiagnòstic basada en 31 auditories tècniques que hem fet a onext en startups Sèrie A-C durant els últims 2 anys.

Senyal #1: Els incidents en producció es multipliquen exponencialment

Què observar:

Mesura el nombre d'incidents crítics en producció (downtime >5 min, degradació de servei, data loss, security breach) en els últims 6 mesos:

• Verd: 0-2 incidents/mes amb tendència estable o decreixent
• Groc: 3-5 incidents/mes o tendència creixent lleu
• Vermell: >6 incidents/mes o creixement >50% en els últims 3 mesos

Red flag crítica: Si els teus incidents s'han duplicat o triplicat en els últims 6 mesos sense que hagis duplicat features o trànsit, tens un problema estructural, no conjuntural.

Per què passa (causes arrel):

Quan els incidents augmenten exponencialment, generalment és per una combinació d'aquests 4 factors:

1. La complexitat del sistema va créixer més ràpid que l'observability

• Vas passar de monòlit a microserveis sense implementar tracing distribuït
• Vas afegir cues, workers, cron jobs, lambdes… però el monitoratge segueix sent "CloudWatch default"
• No tens visibilitat end-to-end de requests crítics (ex: des de checkout a payment a fulfillment)

Resultat: Quan alguna cosa falla, trigues hores a identificar ON va fallar, perquè estàs debuggejant "a cegues".

2. El testing coverage va baixar mentre el codebase creixia

• El coverage era 70% fa un any, ara és 45% (el codi nou s'escriu sense tests)
• Els tests són flaky (1 de cada 3 runs falla per raons no relacionades amb el codi)
• Els tests e2e són inexistents o triguen 45 minuts (ningú no els corre abans de merge)

Resultat: Bugs que els tests haurien de detectar en CI arriben a producció perquè "no tenim temps d'escriure tests".

3. El deploy process no va evolucionar amb el producte

• Segueixes fent deploys manuals encara que l'app va créixer 10x en complexitat
• No tens rollback automàtic (si un deploy trenca producció, trigues 20-60 min a revertir)
• No hi ha staging environment que replica producció fidelment

Resultat: Cada deploy és una ruleta russa. De vegades funciona, de vegades no. Ningú no sap per què.

4. El deute tècnic va assolir massa crítica

• Codi legacy de 3+ anys que ningú no entén però "funciona" (fins que no funciona)
• Dependències crítiques desactualitzades perquè "migrar és arriscat"
• Arquitectura que funcionava per a 100 users/dia ara gestiona 10.000 users/dia (sense refactoring)

Resultat: El sistema està al límit. Qualsevol canvi petit té efectes inesperats (cascading failures).

Cas real: SaaS B2B que va passar de 2 a 18 incidents/mes en 5 mesos

Context:

• Startup Sèrie B, 4 M€ ARR, 22 developers
• Stack: Node.js monòlit + PostgreSQL + Redis + AWS EC2
• Producte: Plataforma d'analytics per a eCommerce

Evolució dels incidents:

• Gener 2024: 2 incidents
• Febrer: 3 incidents
• Març: 5 incidents
• Abril: 9 incidents
• Maig: 14 incidents
• Juny: 18 incidents (les alertes de PagerDuty a les 2 AM es van convertir en rutina)

Causa arrel descoberta en una auditoria de 3 dies:

• Database sense indexació adequada (les queries van augmentar de 50ms a 8 segons en 6 mesos)
• Memory leak en el worker de processament d'analytics (omplia la RAM cada 36 hores → crash)
• Redis configurat amb una eviction policy incorrecta (les dades crítiques s'esborraven sota pressió)
• Logs no estructurats (impossible fer queries útils per a debugging)

Solució implementada (4 setmanes):

• Database optimization: vam afegir índexs a les queries N+1, vam passar de 8s a 120ms
• Vam arreglar el memory leak (va ser 1 línia de codi: EventEmitter sense cleanup)
• Vam reconfigurar Redis + vam afegir monitoring d'evictions
• Vam implementar structured logging amb Datadog

Resultat: De 18 incidents/mes a 1-2 incidents/mes en els següents 3 mesos.

Lliçó: Els incidents no eren "mala sort". Eren símptomes de 4 problemes estructurals que una auditoria de 3 dies va identificar i 4 setmanes de feina van resoldre.

Senyal #2: El temps d'onboarding de nous developers va augmentar 3-4x

Què observar:

Mesura quant triga un developer nou (mid-level o sènior) a ser productiu (fer el seu primer PR útil sense supervisió constant):

• Verd: 1-2 setmanes per al primer PR productiu
• Groc: 3-4 setmanes
• Vermell: >5 setmanes o "mai no arriben a ser realment autònoms"

Red flag crítica: Si fa 2 anys l'onboarding trigava 1 setmana i ara triga 4-6 setmanes, la teva arquitectura s'ha tornat incomprensible. Això NO és normal.

Per què passa:

1. Documentació inexistent o desactualitzada

• El README diu "run npm install" però en realitat necessites 8 passos addicionals no documentats
• L'arquitectura documentada fa 2 anys ja no reflecteix el sistema actual
• El setup del local environment triga 2 dies amb l'ajuda de 3 developers (hauria de trigar 2 hores sense ajuda)

2. Complexitat accidental vs essencial

• Per afegir un camp a un formulari, has de tocar 12 fitxers en 5 carpetes diferents
• Patrons inconsistents: cada feature va ser implementada amb un approach diferent
• Abstraccions "intel·ligents" que van fer el codi més difícil d'entendre, no més fàcil

3. Tribal knowledge (coneixement en caps, no en codi/docs)

• "Per entendre com funciona X, has de preguntar-li a en Joan" (i si en Joan marxa?)
• Codi sense comments, noms de variables críptics, funcions de 400 línies
• Configuracions crítiques que viuen en Slack threads de fa 8 mesos

Autodiagnòstic: El test del "developer fantasma"

Imagina que contractes un developer remot que mai no has conegut en persona. Li dones accés al repo i li demanes:

1. Aixecar el projecte en local
2. Córrer els tests
3. Fer un canvi simple (afegir un camp a una taula + exposar-lo a l'API)
4. Desplegar a staging

Pot fer tot això només llegint la documentació existent, sense preguntar a ningú?

• Sí, en <4 hores: El teu codebase està ben estructurat i documentat ✅
• Sí, però triga 2 dies: Tens deute de documentació important ⚠️
• No, necessita ajuda constant: Tens tribal knowledge crític 🚨

"Vaig contractar un senior developer amb 8 anys d'experiència en Node.js. Va trigar 6 setmanes a fer el seu primer PR sense supervisió. No era un problema de skills, era que el nostre codebase s'havia tornat tan complex i poc documentat que fins i tot els seniors s'hi perdien."

— CTO de Healthtech startup (Madrid), 16 developers

Senyal #3: El temps de deploy va augmentar mentre les features s'alentien

Què observar:

Mesura dues mètriques clau en els últims 12 mesos:

Mètrica 1: Temps de deploy (commit → producció):

• Verd: <30 minuts, estable o decreixent
• Groc: 30-120 minuts
• Vermell: >2 hores o va augmentar >100% en l'últim any

Mètrica 2: Lead time de features (spec → producció):

• Verd: Features petites en 1-3 dies, mitjanes en 1-2 setmanes
• Groc: Features petites en 1 setmana, mitjanes en 3-4 setmanes
• Vermell: Features petites en >2 setmanes, mitjanes en >6 setmanes

Red flag crítica: Si totes dues mètriques van empitjorar simultàniament, la teva arquitectura i/o processos es van convertir en un coll d'ampolla crític.

Per què passa:

1. Arquitectura monolítica sense modularització

• El deploy requereix desplegar TOT el monòlit encara que canviïs 1 línia
• El build time va augmentar de 3 min a 18 min perquè el bundle va créixer sense tree-shaking
• Els tests corren seqüencialment en 45 minuts (sense paral·lelització)

2. Coupling alt entre components

• Per afegir una feature al mòdul A, has de modificar els mòduls B, C, i D
• Els PRs que tocaven 1 fitxer ara toquen 15 fitxers
• El risc de regression va augmentar → més testing manual → més temps

3. La infraestructura no va escalar amb el producte

• Les database queries es van tornar lentes (sense optimització d'índexs)
• El CI/CD segueix corrent en runners bàsics (sense scaling horitzontal)
• El staging environment triga 20 min a aixecar-se perquè està mal configurat

Calculadora d'impacte: Quant et costa el deploy lent?

Si el teu deploy triga 2 hores en lloc de 20 minuts:

• Temps perdut per deploy: 1h 40min extra x 10 deploys/mes = 16,6 hores/mes
• Developers afectats: 2-3 persones bloquejades durant aquest temps
• Cost d'oportunitat: 16,6 hores x 2,5 developers x 65 €/hora = 2.700 €/mes = 32.400 €/any

I això sense comptar:

• Context switching (els developers canvien de tasca durant un deploy llarg, perden focus)
• Fear of deployment (si el deploy triga 2 hores, desplegues menys → les features triguen més a arribar als clients)
• Reduced iteration speed (si un A/B testing requereix 2 deploys, trigues 4 hores en lloc de 40 min)

ROI d'optimitzar el deploy: Invertir 3 setmanes a optimitzar CI/CD (12k € en developer time) t'estalvia 32k €/any. Break-even: 4,5 mesos. ROI any 1: 167%.

Checklist d'autodiagnòstic complet

Fes servir aquest checklist per avaluar si necessites una auditoria tècnica urgent:

Observability & Monitoring (10 punts):

• ❌ Els incidents en producció van augmentar >50% en els últims 6 mesos
• ❌ El MTTR (temps fins a resoldre un incident) és >2 hores
• ❌ No tenim tracing distribuït (en una arquitectura amb >3 serveis)
• ❌ Els logs no estan estructurats (no podem fer queries útils)
• ❌ No tenim alerting basat en SLIs (només alertes genèriques de CPU/RAM)

Code Quality & Testing (10 punts):

• ❌ El coverage de tests és <60% o va baixar >15% en l'últim any
• ❌ Els tests són flaky (>10% de false negatives)
• ❌ No tenim tests e2e per als user journeys crítics
• ❌ Els code reviews triguen >2 dies (per complexitat de codi o falta de tests)
• ❌ L'onboarding de nous developers triga >3 setmanes

Architecture & Performance (10 punts):

• ❌ Les queries a la database triguen >500ms en p95
• ❌ El temps de deploy va augmentar >100% en l'últim any
• ❌ No podem desplegar sense downtime
• ❌ El rollback triga >30 minuts
• ❌ Les features petites triguen >1 setmana a arribar a producció

Documentation & Knowledge (10 punts):

• ❌ El setup del local environment triga >4 hores
• ❌ La documentació d'arquitectura té >6 mesos de desactualització
• ❌ >50% del coneixement crític està en caps d'1-2 persones
• ❌ No hi ha runbooks per a incidents comuns
• ❌ Les decisions tècniques crítiques no estan documentades (només en Slack/memòria)

Interpretació de resultats:

• 0-5 ❌: Stack saludable, només petites millores incrementals
• 6-12 ❌: Deute tècnic moderat, planificar una auditoria en els pròxims 3 mesos
• 13-20 ❌: Deute tècnic significatiu, auditoria recomanada en les pròximes 4-6 setmanes
• >20 ❌: Deute tècnic crític, auditoria urgent (risc de crisi imminent)

Què fa una auditoria tècnica (i què NO fa)

Una auditoria tècnica ben feta NO és "un consultor que critica el teu codi durant 2 setmanes i t'entrega un PDF de 80 pàgines que ningú no llegeix".

Una auditoria efectiva és:

1. Diagnòstic de 2-3 dies (no setmanes)
   • Revisió de l'arquitectura actual (no només codi, també infra i processos)
   • Identificació de bottlenecks crítics (top 5 problemes que causen el 80% del dolor)
   • Entrevistes amb l'equip (developers, devops, product) per entendre els pain points
2. Roadmap prioritzat de remediació (no una llista genèrica de "millors pràctiques")
   • Quick wins (2-4 setmanes, alt impacte, baix esforç)
   • Millores estructurals (2-3 mesos, alt impacte, esforç mitjà)
   • Refactorings llargs (6+ mesos, necessaris però poden esperar)
3. Estimació de ROI per iniciativa
   • Quant temps/diners estalviaràs
   • Quant trigarà a implementar-se
   • Quin és el break-even
4. Ownership clar
   • Què pot fer el teu equip intern
   • Què requereix expertise extern
   • Què és crític vs nice-to-have

Una auditoria efectiva NO és:

• ❌ Un rewrite complet de la teva aplicació (el 99% de les vegades no és necessari)
• ❌ Migrar a l'última tecnologia de moda perquè "és millor"
• ❌ Un informe genèric copiat d'altres projectes
• ❌ Una consultoria de 6 mesos que et deixa dependent

Resultat esperat d'una auditoria ben feta: En 2-3 dies, saps exactament què va malament, per què, i quin és el pla de 12 setmanes per arreglar-ho (amb ROI quantificat per a cada iniciativa).

Reconeixes alguna d'aquestes 3 senyals a la teva startup?

Si has respost "sí" a alguna d'aquestes 3 senyals, no esperis que la situació empitjori:

• Senyal #1: Els incidents en producció es van multiplicar en els últims 6 mesos
• Senyal #2: L'onboarding de developers ara triga 3-4x més que fa 1-2 anys
• Senyal #3: El deploy time i el feature lead time van augmentar simultàniament

Aquestes senyals NO s'arreglen soles. Al contrari: el deute tècnic creix exponencialment si no l'ataques de manera estructurada.

A onext fem auditories tècniques de 2-3 dies per a startups Sèrie A-C. Identifiquem els 5 problemes crítics que causen el 80% del dolor i dissenyem un roadmap de remediació prioritzat per ROI.

Sense rewrites innecessaris. Sense migracions de tecnologia perquè sí. Sense PDFs de 80 pàgines que ningú no llegeix.

Només un diagnòstic clar, un pla accionable, i ROI quantificat.