Qué pasa después de lanzar tu MVP, los costos que nadie mete en la cotización
El presupuesto real empieza después del lanzamiento: soporte, deuda técnica, infraestructura y decisiones que evitan que tu MVP se rompa al crecer.
Qué pasa después de lanzar tu MVP, los costos que nadie mete en la cotización
Los costos de mantenimiento de un MVP casi nunca aparecen en la primera conversación. Todos quieren hablar del lanzamiento, del diseño, del stack, de cuánto tarda la primera versión y de si se puede tener lista para la demo con inversionistas.
Tiene sentido. Lanzar se siente como la meta.
Pero en software, lanzar no es la meta. Es el momento en que el producto deja de vivir en Figma y empieza a recibir golpes de usuarios reales, navegadores raros, pagos fallidos, datos incompletos, bugs que nadie vio venir y founders que descubren que la versión uno era solo el principio.
Ahí aparece el presupuesto que nadie quería mirar.
El MVP no termina cuando llega a producción
Un MVP sirve para validar una hipótesis, no para descansar. Si funciona, vas a necesitar moverlo más rápido. Si no funciona, vas a necesitar cambiarlo. En ambos casos hay trabajo después del lanzamiento.
Ese trabajo puede ser pequeño o grande, pero rara vez es cero.
Después de lanzar empiezan las preguntas incómodas. Quién atiende los bugs. Quién actualiza dependencias. Quién revisa logs cuando algo falla a medianoche. Qué pasa si Stripe cambia algo, si Apple rechaza una actualización, si una integración externa se cae o si un usuario importante encuentra un flujo roto justo antes de cerrar una venta.
Nada de eso suena sexy en una cotización. Pero es lo que separa un prototipo bonito de un producto que puede sobrevivir fuera de la presentación.
Por eso los costos de mantenimiento de un MVP deberían planearse desde el inicio, no cuando el primer cliente ya está molesto.
La deuda técnica no siempre es mala, pero siempre cobra
Hay una frase que se usa demasiado para justificar código desastroso: “es solo un MVP”.
A veces tiene razón. Un MVP no necesita la arquitectura perfecta. No necesita resolver problemas de escala que todavía no existen. No necesita un sistema de permisos digno de un banco si tienes veinte usuarios de prueba.
Pero una cosa es tomar atajos conscientes y otra muy distinta es construir sin dejar mapa.
La deuda técnica buena es una decisión explícita. Sabemos que este panel será manual por ahora. Sabemos que esta integración se va a rehacer si la validación funciona. Sabemos que esta parte no está preparada para miles de usuarios y está bien porque hoy necesitamos aprender, no presumir infraestructura.
La deuda técnica mala es la que nadie documenta, nadie entiende y todos descubren cuando agregar una feature sencilla toma tres semanas.
Ese es el impuesto oculto. No lo pagas el día del lanzamiento. Lo pagas cuando quieres iterar y el producto se resiste.
Lo que realmente entra en mantenimiento
Cuando un founder escucha “mantenimiento”, suele imaginar dos bugs pequeños al mes. Algo tipo: arreglar un botón, ajustar un texto, cambiar un correo.
La realidad es más amplia.
Mantenimiento también es actualizar librerías porque una dependencia tiene una vulnerabilidad. Es revisar hosting porque el consumo subió. Es mejorar monitoreo para no enterarte por un cliente de que algo murió. Es corregir edge cases que no aparecieron con datos de prueba. Es adaptar el producto cuando el feedback real contradice la idea original.
También es soporte técnico. No necesariamente soporte al usuario final, aunque a veces toca, sino soporte al negocio. Ayudar a entender qué falló, qué se puede cambiar rápido, qué conviene dejar igual y qué requiere una decisión de producto antes de tocar código.
En DevAces nos gusta decirlo claro: después del MVP necesitas presupuesto para aprender. Si todo tu dinero se fue en construir la primera versión, cualquier señal del mercado se vuelve un problema en vez de una oportunidad.
Cuánto deberías guardar después de lanzar
No hay una cifra universal, y cualquiera que te venda una respuesta exacta sin conocer tu producto está improvisando con confianza.
Pero hay una regla práctica: si vas a invertir en un MVP, reserva desde el principio una parte para los primeros meses después del lanzamiento. No como lujo. Como parte del costo real del proyecto.
Para productos pequeños, eso puede ser un bloque mensual de soporte y mejoras. Para productos más serios, puede ser una bolsa de horas, monitoreo, mantenimiento de infraestructura y una fase de estabilización. Si tu MVP costó lo suficiente como para doler, deberías tener al menos unos meses de oxígeno para corregir, medir e iterar.
El peor escenario es lanzar, recibir feedback útil y no tener margen para actuar.
Eso pasa más de lo que debería.
La conversación que debes tener antes de firmar
Antes de contratar una agencia, pregunta qué pasa después del lanzamiento. No en abstracto. Pregunta qué incluye la garantía, qué cuenta como bug, qué cuenta como cambio, quién mantiene el repositorio, cómo se manejan incidentes y qué partes del sistema fueron construidas como temporales.
Una buena agencia no debería ofenderse por esas preguntas. Al contrario, debería agradecerlas. Significa que estás pensando como operador, no solo como alguien que quiere “una app”.
También conviene pedir una lectura honesta del producto antes de escalar. Qué está listo para crecer. Qué aguanta unos meses. Qué hay que reescribir si la tracción llega. Esa conversación puede ahorrar mucho dinero, especialmente cuando el MVP empieza a mostrar señales positivas.
Lanzar es el inicio del trabajo real
El MVP no es una versión barata de tu producto final. Es una herramienta para aprender con el menor riesgo posible.
Pero aprender cuesta. Cuesta tiempo, soporte, infraestructura, correcciones y decisiones difíciles sobre qué mejorar y qué ignorar.
Si estás planeando construir uno, no preguntes solo cuánto cuesta desarrollarlo. Pregunta cuánto cuesta mantenerlo vivo después de lanzarlo.
Si quieres aterrizar esa conversación sin humo, en DevAces podemos ayudarte a separar lo que necesitas para lanzar de lo que vas a necesitar para operar. Porque la primera versión importa, sí. Pero lo que haces después de lanzarla suele importar más.