Hay un momento muy concreto en la vida de un MVP que nadie documenta: el día en que deja de fallar por lo que esperabas. Pasa de romperse por bugs a romperse por decisiones. Y eso cambia todo el diagnóstico.
Un producto mínimo viable es una versión lanzada con sus funciones esenciales para medir comportamiento real antes de construir el producto completo. Hasta ahí llega casi toda la literatura disponible. Lo que apenas se documenta es el proceso de ir de MVP a producto, el día después, cuando ese experimento empieza a sostener clientes que pagan.
En los últimos tres años hemos acompañado 38 prototipos en ese tránsito. De esos, 29 fallaron primero en el mismo sitio, y no era el código. Nos sorprendió lo suficiente como para empezar a registrarlo con orden: qué cedió, cuándo, con cuántos usuarios y qué hicieron los equipos las dos semanas siguientes.
Nota de alcance: todas las cifras de este artículo proceden de nuestro registro interno de 38 acompañamientos realizados entre 2022 y 2025, en su mayoría productos B2B de software en fases tempranas. No son estadísticas sectoriales ni están publicadas en estudios independientes, y no deberían extrapolarse a mercados distintos. Las damos porque son las que tenemos, no porque sean representativas.
Lo que sigue es ese registro convertido en método. No es una guía de arquitectura. Es más parecido a una secuencia clínica: síntoma, causa, orden de fractura, diagnóstico diferencial y tratamiento.
Los síntomas que avisan de que tu versión mínima ya no aguanta
Los síntomas aparecen semanas antes de la caída. Siempre. El problema es que se parecen mucho al ruido normal de una empresa joven, y por eso se archivan como «cosas de crecer».
Señales visibles para el usuario: latencias, errores silenciosos y flujos que se atascan
¿Cuál es la primera señal real? No es el error 500. Es el tiempo de respuesta que se duplica sin que nadie lo note, porque pasa de 400 ms a 900 ms y eso sigue «yendo bien».
En uno de los proyectos revisados en octubre de 2023, el endpoint de búsqueda tardaba 1,8 segundos con 60 cuentas activas. Nadie se quejó. A los 140 usuarios tardaba 7 segundos y cerca de un tercio abandonaba el flujo antes de terminar. El equipo llevaba cuatro meses mirando el gráfico equivocado.
El error silencioso es peor que el visible. Un fallo que devuelve un array vacío en vez de reventar deja al usuario pensando que no hay resultados, y a ti pensando que no hay demanda. Hemos visto decisiones de pivote tomadas sobre datos que eran, literalmente, excepciones no capturadas.
Señales internas: tickets repetidos, hotfixes semanales y miedo a tocar el código
Si el mismo ticket entra tres veces en un mes con distinto cliente, no tienes un bug: tienes un diseño incorrecto. La diferencia importa porque uno se arregla en dos horas y el otro en dos sprints.
La cosa es que el indicador más fiable que conocemos no es técnico, es emocional. Cuando alguien del equipo dice «esa parte mejor no la toques», ahí hay una fractura. Lo registramos: en 22 de los 38 acompañamientos, el módulo que daba miedo fue exactamente el que falló al crecer.
Otro marcador: la frecuencia de despliegues de urgencia. Por encima de dos hotfixes semanales sostenidos durante un mes, en torno a tres de cada cuatro proyectos acabaron necesitando intervención estructural y no solo parches puntuales.
¿Por qué el primer punto de rotura casi nunca está en el código?
Durante mucho tiempo creímos que crecer era un problema de ingeniería. En 29 de los 38 proyectos, la primera grieta estaba en una decisión de negocio tomada seis meses antes, no en una línea mal escrita. Cambiamos el orden de la auditoría a partir de ahí.
Atajos de validación que se convierten en estructura permanente
Todo prototipo se construye sobre atajos conscientes. Un campo de texto donde debería haber una tabla. Un Google Sheet haciendo de base de datos. Un cron que corre a las 3 de la mañana y nadie sabe quién lo configuró.
Imagina que esos atajos tuvieran fecha de caducidad escrita. No la tienen, y ahí está la trampa: al funcionar, dejan de verse. Se vuelven infraestructura por omisión. El apaño se convierte en cimiento sin que nadie firme la decisión.
Nos pasó con un cliente del sector logístico en 2022. Habíamos montado la asignación de pedidos con una regla única porque solo había un almacén. Cuando abrieron el segundo, la regla no se podía extender: había que reescribir el dominio completo. Tres semanas perdidas por una decisión de quince minutos.
El onboarding y la activación: la grieta que nadie mide en la fase de prueba
En fase de validación el alta la hace una persona del equipo. A mano. Con una llamada. Y funciona perfecto, porque un humano resuelve cualquier ambigüedad del formulario.
El día que llegan 40 registros en una semana, ese humano desaparece del proceso y aparece la verdad: algo más de la mitad no completa la configuración inicial. No es un problema de escala técnica, es que nunca existió un onboarding, existía un favor. Si estás viendo caídas con volúmenes bajos, merece la pena revisar las causas de por qué una app de Lovable se cae con 50 usuarios, porque el patrón de origen es prácticamente idéntico en herramientas no-code y en desarrollo tradicional.
El orden real de fractura: datos, operaciones, infraestructura y equipo
Al pasar de una versión mínima a un producto en uso, lo primero que cede casi nunca es el código. El orden habitual de fractura es modelo de datos, procesos manuales, costes de infraestructura y, por último, el equipo fundador. Cada capa falla porque depende de decisiones tomadas durante la validación.
- Modelo de datos. El esquema se diseñó para demostrar una hipótesis, no para relacionar entidades.
- Procesos manuales. Las tareas que el usuario cree automáticas dejan de caber en una semana laboral.
- Costes de infraestructura. Consultas sin índice multiplican la factura sin aviso previo.
- Equipo fundador. El perfil técnico se agota de sostener decisiones que ya no defiende.
Aquí viene lo que más nos costó aceptar: ese orden es casi siempre el mismo. No es azar, es dependencia estructural.
Primero cede el modelo de datos: esquemas pensados para cien usuarios, no para diez mil
El esquema se diseñó para demostrar una hipótesis. Entidades planas, pocas relaciones, campos JSON donde no había tiempo de pensar. Perfecto para validar.
El punto de ruptura que hemos observado está entre 800 y 3.000 registros por tabla crítica, no en millones. Suena bajo. Lo es: el problema no es el volumen, es que las consultas que antes eran directas empiezan a necesitar joins que el modelo no permite sin duplicar información.
Y cuando duplicas información para salir del paso, introduces estados inconsistentes. Ese es el momento exacto en que el soporte empieza a recibir avisos de «mis números no cuadran». Dos tercios de los equipos acompañados pasaron por esta fase antes de tocar un servidor.
Después revientan los procesos manuales que sostenían la experiencia
Total, que la base de datos se estabiliza con parches y entonces cede lo siguiente: las personas.
Cada prototipo esconde entre 4 y 9 tareas manuales que el usuario percibe como automáticas. Facturación revisada a mano. Altas validadas una por una. Informes montados en una hoja de cálculo los viernes por la tarde. Es el patrón que la literatura llama MVP «concierge», solo que nadie avisó de que caducaba.
Con 20 clientes eso son seis horas semanales. Con 90 clientes son cuarenta, y no hay nadie para hacerlas. El síntoma visible es un fundador contestando correos a medianoche; la causa es que la operación nunca se diseñó, se improvisó. Reconozcámoslo: nosotros tardamos dos años en incluir el inventario de tareas manuales en la auditoría inicial, y fue el cambio que más fallos nos permitió anticipar.
Al final llegan los costes de infraestructura y la rotación del equipo fundador
Los costes aparecen tarde y de golpe. Una factura de 90 € mensuales se convierte en 1.400 € en siete semanas porque una consulta sin índice se ejecuta 40.000 veces al día.
¿Y la rotación? Es el último eslabón y el más caro. En 9 de los proyectos registrados, el perfil técnico fundador se fue entre el mes 14 y el mes 20, justo después del periodo de hotfixes continuos. No se van por dinero: se van agotados de sostener decisiones que ya no defienden.
Cómo diagnosticar tu caso antes de reescribir una sola línea
La tentación universal es reescribir. Y es casi siempre la respuesta equivocada, porque reescribes la parte que entiendes y no la que falla.
Tres métricas que distinguen un problema de escala de un problema de encaje
Hay una pregunta que lo decide todo: ¿se rompe porque hay muchos usuarios o porque los usuarios que hay no encajan? Son enfermedades distintas y el tratamiento es opuesto.
- Retención a 30 días por cohorte de entrada
- Tiempo hasta el primer valor real del usuario
- Ratio entre incidencias nuevas e incidencias repetidas
Si la retención cae uniformemente en todas las cohortes, no tienes un problema de escala. Tienes un problema de encaje disfrazado de caída técnica. La señal de escala genuina es distinta: la retención se mantiene en cohortes antiguas y se hunde solo en las nuevas, las que entraron cuando el sistema ya iba lento.
El tercer ratio es el más útil y el que nadie calcula. Por encima del 60% de incidencias repetidas, el fallo es estructural. Por debajo del 25%, son bugs normales y conviene no dramatizar.
Prueba de carga narrativa: simular el décimo cliente, no el millonésimo
Las pruebas de carga clásicas te dicen cuántas peticiones soporta el servidor. Útil, pero responde una pregunta que no te estás haciendo.
Lo que proponemos es otra cosa: coge tu cliente número diez y escribe, en prosa, toda su vida en el sistema durante tres meses. Alta, configuración, invitación a dos compañeros, cambio de plan, exportación de datos, baja de un usuario, factura rectificativa.
En la gran mayoría de las sesiones donde hemos hecho este ejercicio aparecen entre tres y cinco pasos que el sistema simplemente no contempla. Ninguna herramienta de carga los habría detectado, porque no son un problema de rendimiento sino de huecos en el modelo. Y es ahí donde se decide si hay que reparar o reconstruir.
Tratamiento: qué reparar, qué tirar y qué dejar roto a propósito
Esta es la sección que más discusiones genera cuando la planteamos en una sala, porque implica aceptar que parte del sistema se queda mal hecho de forma deliberada.
Reparaciones que compran tiempo sin congelar el roadmap
La regla que aplicamos: solo se interviene lo que bloquea ingresos o lo que bloquea aprendizaje. Todo lo demás espera, aunque duela.
En la práctica eso suele traducirse en cuatro movimientos concretos. Índices en las tres consultas más lentas, que en un proyecto de abril de 2024 bajó el percentil 95 de 4,2 s a 680 ms en dos días de trabajo. Extracción del modelo de datos crítico a un esquema normalizado, dejando el resto como está. Automatización de la tarea manual que más horas consume, una sola, la más caraa. Y monitorización real de los tres indicadores del apartado anterior.
¿Por qué no más? Porque cada reparación adicional congela el roadmap entre dos y cinco semanas, y un equipo de cinco personas no puede permitirse un trimestre sin entregar nada nuevo. El coste de oportunidad es invisible en el acta de la reunión y brutal en la cuenta de resultados.
Una transformación completa desde la primera versión hasta una plataforma estable rara vez baja de los cinco meses; en nuestra experiencia acompañando el camino de MVP a SaaS se recorre mejor en tramos cortos con validación entre cada uno que en un único proyecto monolítico de rediseño.
Deuda técnica que conviene mantener viva hasta la siguiente validación
Hay deuda que es una bomba y deuda que es un seguro. Confundirlas cuesta meses.
La regla de clasificación que usamos tiene dos preguntas: ¿esta parte del sistema va a sobrevivir a la próxima decisión de negocio?, ¿su fallo afecta a datos o solo a experiencia? Si la respuesta es «probablemente no sobreviva» y «solo afecta a experiencia», se deja roto. A propósito. Documentado.
Ejemplo real: un panel de administración interno que tardaba 11 segundos en cargar. Insufrible. También irrelevante, porque lo usaban dos personas al día y el módulo iba a desaparecer en el siguiente trimestre. Arreglarlo habría costado 30 horas. No lo tocamos y fue la decisión correcta, aunque durante dos meses el equipo nos lo recordó en cada reunión.
¿Funciona siempre esta clasificación? No. Hemos fallado al menos tres veces, y el patrón del error es idéntico: dimos por muerto un módulo que luego resultó central. El coste de equivocarse por este lado, eso sí, es menor que el de reescribir el sistema entero.
Qué cambia en la forma de decidir cuando el prototipo ya es un producto
El cambio profundo no está en la arquitectura. Está en quién paga el error.
En fase de validación, una decisión equivocada cuesta una semana de tu tiempo. Con 90 clientes pagando, la misma decisión cuesta facturación, reputación y, a veces, a la persona que la sostiene. Esa asimetría obliga a cambiar el método, no solo el stack.
Lo que observamos en los equipos que hacen bien el tránsito es que incorporan una pregunta nueva antes de cada entrega: ¿esto se puede deshacer? Si la respuesta es sí, se lanza rápido. Si no se puede deshacer, se discute dos días más. Suena lento y es exactamente lo contrario: reduce los hotfixes.
Creímos durante un tiempo que el problema de escalar un MVP era de madurez técnica. Nuestro registro dice otra cosa: es un problema de orden. Si atiendes los datos antes que la infraestructura, y la operación antes que el equipo, la reescritura completa deja de ser necesaria en la mayoría de los escenarios.
Y si no te queda claro por dónde empezar, empieza por lo más barato: inventaría tus tareas manuales. Es gratis, lleva una tarde y suele señalar la grieta real con una precisión que ninguna auditoría de código iguala.
Preguntas frecuentes
¿Qué pasa después de lanzar un MVP?
Empieza una fase que casi nadie planifica. Durante las primeras semanas con usuarios reales ceden, en este orden, el modelo de datos, las tareas manuales ocultas, los costes de infraestructura y la resistencia del equipo fundador. Los síntomas aparecen semanas antes del fallo visible.
¿Cuál es la diferencia entre MVP y prototipo?
El prototipo valida usabilidad o concepto sin llegar al mercado: puede ser una maqueta sin funcionamiento real. La versión mínima viable sí se expone a usuarios reales para medir comportamiento y disposición a pagar. Por eso solo la segunda genera deuda estructural que después habrá que diagnosticar.
¿Cuándo hay que dejar de iterar sobre el MVP?
Cuando el ratio de incidencias repetidas supera el 60% y las tareas manuales ocupan más de una jornada semanal completa. A partir de ahí cada iteración se apoya en cimientos que ya no sostienen, y conviene intervenir el modelo de datos antes de añadir funciones nuevas.
¿Qué errores se cometen al escalar un MVP?
El más común es confundirlo con una versión incompleta del producto final en lugar de un experimento de aprendizaje. El segundo es reescribir antes de diagnosticar: se reconstruye la parte que el equipo entiende, no la que falla. El tercero, arreglar toda la deuda a la vez.
