CTO Advisory Report

NutriFlow — Diagnóstico Técnico

Auditoría de deuda técnica · Due diligence pre-Serie A · Plan de acción Q3 2026
Cliente: NutriFlow SaaS
Solicitante: Javier M. (CTO)
Fecha: 12 jun 2026
Asesor: CULTIVA IA · Consultoría Técnica
60.6
/ 100
Deuda técnica Media-Alta — Acción inmediata recomendada
NutriFlow presenta bloqueos estructurales en arquitectura e infraestructura que explican la caída de velocidad. La seguridad es el riesgo más crítico de cara a la due diligence inversora y al cumplimiento RGPD del sector salud. Con el plan correcto, 2 sprints resuelven los P0.
Riesgo ALTO
Estado actual de ingeniería (métricas DORA)
~2/mes
Frecuencia deploy
▼ Objetivo: diario
4–6 días
Lead time cambios
▼ Objetivo: <1 día
~12%
Change failure rate
▼ Objetivo: <5%
3–6h
MTTR (tiempo recuper.)
▼ Objetivo: <1h
Desglose por categoría
Arquitectura
72.5
Med-High
Infraestructura
64.2
Med-High
Seguridad
57.5
Medio
Calidad código
57.4
Medio
Performance
44.2
Medio
Ratios de equipo e ingeniería
Cobertura tests
28%
Objetivo: ≥70%
Tiempo mantenimiento
~42%
Objetivo: <25%
Bus factor crítico
1 persona
Solo CTO deploya
Secretos en repo
Sí (.env)
P0 RGPD / GDPR
Inventario de deuda técnica priorizado
Item Área Severidad Coste estimado Blast radius Score prioridad
.env commiteado con secretos
RGPDSerie A
Seguridad P0 0.5 días Todo el sistema INMEDIATO
Bus factor CTO único en deploys
opsresiliencia
Infraestructura P0 3 días Todo el equipo INMEDIATO
JWT homemade sin rotación de tokens
authRGPD
Seguridad P1 5 días 100% usuarios ALTA
Sin APM backend (monitoring ciego)
observabilidad
Infraestructura P1 2 días Todos los servicios ALTA
CD automatizado ausente
CI/CDvelocity
Infraestructura P1 8 días Todo el flujo dev ALTA
Monolito Rails sin límites de dominio
arquitecturaescalado
Arquitectura P2 30–60 días Todo el sistema MEDIA
Cobertura tests al 28%
calidadregresión
Calidad código P2 15 días Velocidad features MEDIA
Sin auditoría de logs (datos pacientes)
RGPD art.30salud
Seguridad P1 4 días Cumplimiento legal ALTA
Acciones prioritarias — Plan de 90 días
1
Seguridad P0: secretos y autenticación
Riesgo legal inmediato · Due diligence Serie A · RGPD art.5
Rotar todos los secretos y mover a Vault/Doppler (día 1)
Revocar el .env del historial git (git-filter-repo)
Migrar auth a devise-jwt con rotación + refresh tokens
Implementar audit log para acceso a datos de pacientes
4.5 días 1 dev senior Semana 1
2
CD automatizado + eliminar bus factor
Desbloquea la velocidad del equipo · 2x frecuencia de deploy
Configurar GitHub Actions deploy a staging automático
Implementar deploy a producción con approval gate (no solo CTO)
Documentar runbook de deploys y emergencias
Formar a 2 devs senior en el proceso de release
11 días 1 DevOps + 1 senior Semanas 2–3
3
APM backend + alertas proactivas
Visibilidad operacional · Reduce MTTR de 6h a <30min
Integrar Datadog APM en Rails (o Scout APM si coste es barrera)
Definir SLOs: p95 <200ms, uptime 99.9%, error rate <0.5%
Crear dashboard de salud visible para todo el equipo
Configurar alertas PagerDuty con rotación de on-call sostenible
2 días 1 dev Semana 2
Roadmap técnico 90 días
Semana 1 — P0 Urgente
Seguridad y due diligence
  • Rotar secretos → Vault/Doppler
  • Audit logs RGPD activados
  • JWT con rotación real
Semanas 2–3 — Infra
CD automático + observabilidad
  • GitHub Actions: deploy staging/prod
  • Runbook + 2 deployadores en equipo
  • APM Datadog + SLOs definidos
Mes 2 — Calidad
Tests y estabilidad de producto
  • Cobertura tests: 28% → 55%
  • Revisión de código como mentoring
  • Primeras ADRs documentadas
Mes 3 — Arquitectura
Modularización del monolito
  • Bounded contexts definidos
  • 1er servicio extraído (notificaciones)
  • API gateway interno (Rack middleware)
Post-Serie A — Escala
Preparación para 5x usuarios
  • Auto-scaling en Hetzner → Kubernetes
  • Contratación: 2 seniors + 1 SRE
  • Tests al 75%+ · Deploys diarios
ADR-001 — Build vs Buy: Sistema de autenticación
Contexto: JWT homemade sin rotación de tokens en sistema con datos de pacientes (RGPD). Decisión: mantener, construir nuevo, o comprar solución probada.
Criterio Peso Mantener (actual) Devise-JWT (build) Auth0 (buy) ★
Soluciona el problema core 30% 3 8 9
Riesgo migración 20% 9 7 6
TCO a 3 años (€) 25% ~4.000€ (riesgo legal) ~8.000€ (dev time) ~6.000€ (150€/mes)
Estabilidad del vendor 15% N/A N/A (OSS) 9
Esfuerzo integración 10% 1 (ya existe) 7 8
SCORE PONDERADO 5.2 7.6 7.9 ✓ ELEGIDO
Decisión: Adoptar Auth0 (tier Essentials, ~150€/mes). La autenticación NO es IP core de NutriFlow. Auth0 resuelve RGPD, MFA, audit logs y escalado en <2 días de integración. Alternativa Devise-JWT si el board rechaza vendors externos.
Recomendaciones estratégicas para Serie A
🔴
Auditoría de seguridad externa antes de septiembre — Los inversores pedirán evidencia de pentesting. Presupuesto estimado: 4.000–8.000€. Gestionar ahora.
🟠
Dedicar 25–30% de los sprints a reducción de deuda — No pedir permiso al board. Es el único camino para restaurar la velocidad de entrega de features.
🟡
Documentar las 5 ADRs de las últimas decisiones no documentadas — Los inversores técnicos revisan cómo se toman decisiones, no solo qué se decidió.
🔵
Plan de contratación post-ronda — Con 5x escala: +2 senior Rails, +1 SRE, +1 QA engineer. Iniciar pipeline de recruiting ahora para tener offertas en octubre.
🟢
Fortaleza: equipo cohesionado con dominio del negocio — El equipo de 6 ingenieros conoce profundamente NutriFlow. La deuda es de proceso, no de personas. Punto fuerte en pitch inversores.
🟢
Rails + PostgreSQL es la elección correcta para esta fase — No cambiar de stack. El monolito Rails tiene décadas de madurez para SaaS B2B. La solución es modularizar, no reescribir.
Pregunta para la próxima reunión del equipo: "Si nuestro tráfico se multiplica por 10 mañana, ¿qué se rompe primero?" — Responder esta pregunta y documentarla como ADR.
Esfuerzo total estimado
346
Story points totales
~3 sprints
Para reducir P0+P1
25–30%
Capacidad recomendada
de cada sprint
6 → 8
Equipo recomendado
+2 seniors post-ronda