La mayoría de las auditorías de MVP producen un documento. Una útil produce decisiones: qué está ardiendo, qué puede esperar y cuánto cuesta arreglarlo.
Una auditoría técnica de MVP responde a una pregunta: ¿puede esta base de código sostener los próximos doce meses del negocio y, si no, qué exactamente debe cambiar? Todo lo demás — preferencias de herramientas, debates de estilo, elección de framework — es ruido.
Esta es la checklist que recorremos en las primeras 48 horas. Está ordenada deliberadamente por coste del error: lo de arriba puede acabar con una empresa, lo de abajo cuesta velocidad.
1. Integridad del dinero y de los datos (mayor coste de fallo)
Si el producto mueve dinero o guarda datos regulados, esto va primero. Los fallos aquí no son incidentes — son pasivos. Buscamos:
- Si los saldos se derivan de un libro mayor append-only, o se guardan como un número mutable que el código puede sobrescribir
- Idempotencia en cada ruta de pago y webhook — ¿una petición reintentada puede cobrar o abonar dos veces?
- Usar decimales exactos o unidades enteras con reglas monetarias.
- Fronteras transaccionales: ¿puede un fallo parcial dejar el dinero duplicado o en ninguna parte?
- Conciliación: ¿existe algún proceso que detecte una discrepancia, o se enteraría por un cliente?
2. Seguridad y control de acceso
- Autorización comprobada en el servidor en cada petición, o asumida porque la interfaz oculta el botón
- Secretos en variables de entorno y un gestor de secretos, no en el historial del repositorio
- PII y datos de tarjeta: qué se guarda, dónde, y si debería guardarse
- Vulnerabilidades de dependencias realmente alcanzables, no solo un número rojo en un informe
- Aislamiento multi-tenant: ¿puede una petición manipulada leer datos de otro cliente?
3. Arquitectura y límites de escalado
No buscamos elegancia. Buscamos el muro concreto contra el que choca el sistema, y a qué distancia está.
- Los puntos únicos de fallo — la base de datos, la cola, el servicio al que todos llaman
- Patrones de consulta correctos con 1.000 filas y fatales con 1.000.000 (N+1, índices ausentes, escaneos sin límite)
- Si se puede desplegar sin caída de servicio, y si alguien lo ha intentado alguna vez
- Acoplamiento que impide entregar una funcionalidad sin tocar cinco módulos
- Si la arquitectura encaja con el tamaño del equipo — microservicios con cuatro ingenieros son un problema de escalado, no una solución
4. Entrega y operaciones
Las bases de código no se degradan solas; el proceso decide a qué velocidad. Lo que medimos:
| Señal | Saludable | Señal de alarma |
|---|---|---|
| Frecuencia de despliegue | Bajo demanda, varias veces por semana | Mensual, ceremonial, temida |
| Tiempo de entrega de un cambio pequeño | Horas a un día | Semanas |
| Rollback | Un comando, practicado | Teórico |
| Cobertura de test donde importa | Rutas de dinero y auth cubiertas | Porcentaje alto, rutas críticas sin test |
| Observabilidad | Detectas incidentes antes que los clientes | Los clientes son tu monitorización |
5. Deuda técnica: triada, no listada
Toda base de código tiene deuda. Una lista de ella es inútil. Lo que importa es la clasificación en tres cubos:
- Bloqueante — impide la roadmap o pone en riesgo dinero/datos. Arreglar ahora.
- Acumulativa — hace más lento cada cambio futuro. Planificar deliberadamente.
- Cosmética — ofende al gusto, no cuesta nada. Dejarla en paz.
El objetivo de una auditoría no es encontrar todo lo que está mal. Es encontrar las pocas cosas suficientemente mal como para importar, y ser preciso sobre lo que cuestan.
Qué deberías recibir al final
- Una lista priorizada de hallazgos con severidad e impacto de negocio — no un catálogo
- Por cada hallazgo: la solución, una estimación realista de esfuerzo y qué pasa si no se hace nada
- Una roadmap secuenciada: este trimestre, el siguiente, más adelante
- Evidencia — la consulta, el endpoint, la línea concreta — para que tu equipo pueda verificar en vez de confiar
Convertir la revisión inicial en trabajo verificable
Una revisión limitada describe cobertura, no ausencia total de defectos. Cada hallazgo debe poder verificarse independientemente.
- Vincular recorrido afectado, evidencia y condiciones de reproducción.
- Separar defectos observados, riesgos posibles y áreas inaccesibles.
- Asignar responsable y prueba de regresión a cada corrección.
Preguntas frecuentes
¿Cuánto dura una auditoría técnica de MVP?
Una auditoría enfocada de una base de código típica en fase seed lleva de 3 a 10 días laborables según el tamaño y cuánto del sistema mueve dinero. Las primeras 48 horas cubren las áreas de mayor riesgo — flujos de dinero, seguridad y límites de escalado — lo que normalmente basta para saber si hay un problema serio.
¿Necesitáis acceso a nuestros sistemas de producción?
No. Acceso de lectura al repositorio, la arquitectura tal como está desplegada y una sesión con un ingeniero son suficientes para la evaluación. El acceso a producción solo hace falta si además se nos pide ayudar con incidentes en curso.
¿Qué diferencia hay entre una revisión de código y una auditoría técnica?
Una revisión de código evalúa un cambio. Una auditoría evalúa el sistema frente al plan de negocio: si puede sostener la roadmap, sobrevivir al escalado, pasar una due diligence de inversores y no perder dinero. Cubre arquitectura, integridad de datos, seguridad y proceso de entrega — no solo código.
¿Una auditoría nos dirá que reescribamos todo?
Casi nunca, y desconfía de quien responda por defecto con una reescritura. Las reescrituras son la opción más cara y normalmente la equivocada. En la mayoría de los casos, un número pequeño de correcciones dirigidas elimina el riesgo real.
¿Qué ocurre si faltan accesos al código o infraestructura?
Los controles afectados quedan sin verificar. Indica qué decisión impide esa carencia. Una presentación aporta contexto, pero no sustituye evidencia de ejecución.
¿Quieres aplicarlo a tu base de código?
Entregamos hallazgos priorizados con estimaciones de esfuerzo — no un PDF de 50 páginas. Dos semanas, alcance cerrado.
Para seguir leyendo
Cómo arreglar un MVP roto (sin empezar de cero)
Casi todo fundador con un MVP roto pregunta si reescribirlo. Casi siempre la respuesta es no — y la razón es aritmética, no sentimental.
Deuda técnica en startups: ¿cuánta es demasiada?
Toda startup tiene deuda técnica, y la mayor parte fue la decisión correcta. La pregunta no es cómo eliminarla — es qué partes cobran unos intereses que ya no puedes permitirte.