--- title: "Evita deuda técnica en MVP de 12 semanas: guía práctica" description: "Reglas para evitar deuda técnica en MVP: CI/CD semana 1, tests, despliegue paralelo. Decisiones que cuestan caro si se ignoran." slug: "como-evitar-deuda-tecnica-en-mvp-de-12-semanas" url: "https://catalizadora.ai/blog/como-evitar-deuda-tecnica-en-mvp-de-12-semanas" cluster: "software-medida/evitar-deuda-tecnica" author: "Pablo Estrada" published_at: "2026-05-11T12:00:00+00:00" updated_at: "2026-06-19T19:59:51.42746+00:00" read_minutes: "6" lang: "es" --- # Evita deuda técnica en MVP de 12 semanas: guía práctica > Reglas para evitar deuda técnica en MVP: CI/CD semana 1, tests, despliegue paralelo. Decisiones que cuestan caro si se ignoran. 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](https://catalizadora.ai/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](https://catalizadora.ai/magia/core) es el camino. Sin retainers, sin licencias atadas, código a tu nombre. ## Preguntas frecuentes ### ¿Es posible construir un MVP en 12 semanas sin deuda técnica? Sí, si CI/CD está activo desde la semana 1, los tests automatizados son parte del Definition of Done y la arquitectura se valida antes del primer commit de producción. Lo que no es posible es construir sin trade-offs: la diferencia entre deuda técnica controlada y deuda técnica acumulada está en si la documentaste o no. ### ¿Qué deuda técnica conviene aceptar a propósito en un MVP? Tres tipos: cobertura de tests menor a 80 por ciento en código que no toca seguridad o dinero, falta de internacionalización si solo lanzas en un país, y dashboards de observabilidad incompletos. Estas decisiones se documentan en un Architecture Decision Record con fecha y criterio de pago. ### ¿Qué deuda técnica nunca conviene aceptar? Tres tipos: falta de audit log en flujos financieros, manejo de secretos en código o en variables sin rotación, y autenticación sin MFA para roles administrativos. Cualquiera de las tres se vuelve un incidente de seguridad en producción, no una nota técnica. ### ¿Cómo medir si el MVP tiene deuda técnica controlada? Cinco métricas: cobertura de tests automatizados arriba de 70 por ciento en módulos críticos, tiempo de build menor a 10 minutos, deploy a producción en menos de 30 minutos, número de issues etiquetados como 'tech debt' menor al 20 por ciento del backlog, y un ADR firmado por cada decisión técnica reversible. ### ¿Qué hacer si heredo un MVP con deuda técnica acumulada? Auditar primero: identificar los tres módulos que rompen más seguido en producción, los tres archivos con más complejidad ciclomática y los tres flujos sin tests. Pagar deuda en esos nueve puntos primero, no reescribir todo. Reescribir un MVP funcional es la decisión más cara y más común del segundo año. --- Source: https://catalizadora.ai/blog/como-evitar-deuda-tecnica-en-mvp-de-12-semanas Author: Pablo Estrada — AI Catalyst, LLC (catalizadora.ai)