Para evitar deuda técnica en un MVP de 12 semanas necesitas tres cosas: CI/CD activo desde la semana 1, tests automatizados como parte del Definition of Done, y un Architecture Decision Record por cada decisión reversible. Sin estos tres pilares, lo que parece velocidad temprana se cobra con un segundo año donde el equipo dedica más tiempo a apagar fuegos que a construir features. Lo que antes tomaba 30 ingenieros y 18 meses lo entregamos en 12 semanas, pero sin estas reglas no entregas, hipotecas.
La deuda técnica no es un pecado: es un trade-off explícito o implícito. La diferencia entre un equipo que escala y uno que se atora está en cuál de los dos es.
Las tres reglas que sostienen un MVP limpio
Regla 1: CI/CD activo desde el primer pull request
CI/CD no es un nice-to-have de la semana 8. Es un requisito de la semana 1. La primera línea de código de producción debe pasar por un pipeline que corre lint, type check, tests unitarios y build antes de poder mergearse a main.
Stack defensible: GitHub Actions para el pipeline, Vitest o Jest para tests, ESLint y Prettier para estilo, Husky para hooks pre-commit. Tiempo de setup: medio día. Costo de no hacerlo: dos a tres semanas de retrabajo en la semana 10 cuando todo se rompe junto.
Regla 2: Tests como parte del Definition of Done
Un feature no está "Done" si no tiene tests. La cobertura objetivo depende del módulo:
| Tipo de módulo | Cobertura mínima | Por qué |
|---|---|---|
| Flujos de dinero | 90 por ciento | Cada bug es un incidente de negocio |
| Autenticación y permisos | 90 por ciento | Cada bug es un incidente de seguridad |
| Lógica de negocio core | 80 por ciento | Soporte y validación operativa |
| API endpoints | 70 por ciento | Integración con cliente y terceros |
| UI y formularios | 50 por ciento | E2E cubre lo crítico |
| Helpers y utilidades | 70 por ciento | Reutilización amplia |
Si tu MVP no tiene esta tabla escrita en el README, ya estás endeudado.
Regla 3: ADRs por cada decisión técnica reversible
Architecture Decision Records (ADRs) son notas markdown de máximo una página que documentan por qué tomaste una decisión técnica. Una decisión por archivo, con fecha, autor, contexto, opciones consideradas y trade-offs aceptados.
Ejemplo real: "ADR 007: Por qué elegimos Postgres en lugar de DynamoDB para el módulo de cobranza. Decisión: Postgres con Row Level Security. Trade-off: latencia un poco mayor en lecturas masivas, ganancia de queries SQL ad hoc para reportería. Pagar deuda si lecturas superan 10,000 RPS sostenidas."
Sin ADRs, en el mes 9 nadie recuerda por qué hicieron lo que hicieron y se reescribe lo que no debería tocarse.
El caso real: 530 commits en 12 semanas con CI/CD desde el día uno
En un proyecto reciente con una plataforma de ecommerce con IA, el equipo distribuido entregó:
- 530 commits y 945,000 líneas de código en pocas semanas
- 14 repositorios en una organización privada
- 335 tests implementados al cierre del audit
- 264 issues trackeados en Linear con estimación Fibonacci
- 3 marketplace adapters funcionando completamente en staging
- 8 DAGs de Airflow operacionales
El sprint audit identificó bottlenecks (19 PRs en review esperando aprobación, CTO desconectado 9 días, 1 desarrollador ahead of schedule) en un punto en el tiempo donde otros equipos hubieran perdido visibilidad. La razón por la que se pudo auditar: cada decisión técnica estaba documentada en ADR y cada feature tenía tests automatizados corriendo en CI.
Sin esa infraestructura, el "audit" hubiera sido un comité de 4 horas con powerpoints. Con esa infraestructura, fue una consulta a GitHub y a Linear de 30 minutos.
La trampa de "esto lo arreglo después"
La frase más cara del MVP es "esto lo arreglo después". El "después" en una pyme tiene cuatro destinos posibles y solo uno bueno:
- Se arregla cuando se cae en producción y duele dinero. (Caro)
- Se arregla cuando entra un developer nuevo y tarda 3 semanas en entender el código. (Caro)
- Se arregla cuando el cliente pide una feature que toca esa zona. (Caro)
- Se arregla en un sprint dedicado a tech debt programado con anticipación. (Barato)
Si no tienes sprints de tech debt agendados desde la semana 1, los otros tres destinos te van a encontrar.
Las decisiones que cuestan caro si se postergan
Cinco decisiones técnicas que duelen exponencialmente si las dejas para después.
Primero, multitenancy. Si arrancas con una tabla de usuarios sin organization_id, migrar después es entre 4 y 8 semanas de trabajo. Mete organization_id desde el primer migration aunque solo tengas un cliente.
Segundo, audit log inmutable en flujos financieros. Append-only, hash chain SHA-256, deny update y delete vía RLS. Implementarlo en semana 1 toma 2 días. Implementarlo en semana 30 toma 3 semanas y requiere migración de datos históricos.
Tercero, internacionalización. Si vas a operar en más de un país, mete i18n keys desde el primer string. Migrar hard-coded strings después toma entre 2 y 4 semanas y siempre dejas casos abiertos.
Cuarto, manejo de secretos. Variables de entorno cifradas, rotación automática cada 90 días, secrets manager en producción. Implementar después de un incidente es 10 veces más caro y siempre acompaña una llamada incómoda con el cliente.
Quinto, observabilidad básica. Sentry, structured logs, dashboards de KPI técnico. Sin esto operas a ciegas y el primer incidente de producción te toma horas en diagnosticar lo que con observabilidad se ve en 5 minutos.
Cómo medir si tu MVP está sano
Cinco métricas concretas que puedes calcular hoy:
- Cobertura de tests automatizados arriba de 70 por ciento en módulos críticos
- Tiempo de build menor a 10 minutos
- Tiempo de deploy a producción menor a 30 minutos
- Issues etiquetados como "tech debt" menores al 20 por ciento del backlog total
- Un ADR firmado por cada decisión técnica reversible
Si tres o más métricas están en rojo, dedica el siguiente sprint a pagar deuda. No esperes al "después".
Próximos pasos
Si estás arrancando un MVP de 12 semanas o ya tienes uno corriendo y empiezas a sentir la fricción, las tres reglas (CI/CD desde el día uno, tests como Definition of Done, ADRs por decisión) son la diferencia entre escalar y reescribir.
En MAGIA Forge construimos software a medida con CI/CD activo desde la semana 1, pruebas automatizadas en cada release y hardening de producción en 12 semanas por 20,000 USD. Para automatización empresarial sobre arquitectura validada, MAGIA Core es el camino. Sin retainers, sin licencias atadas, código a tu nombre.