
Por Thomas Cohen, fundador de Maestro
Por qué mi MVP no-code nunca se termina: el día 9 y el 20 % que queda
Las pantallas existen, la demostración funciona y el pago de prueba pasa. Después, el proyecto se detiene y nadie sabe decir por qué. El relato de un proveedor que entrega MVP no-code, lo que contiene el último quinto y por qué se paga tan caro cuando llega después de anunciar la fecha de lanzamiento.
Un proveedor que entrega MVP no-code escribe en Reddit (r/nocode, julio de 2026) que los siete primeros días dan la impresión de ser un mago y que el noveno lo rompe todo: casos límite de acceso y pantallas vacías que nadie ha diseñado. Tu MVP nunca se termina porque el último quinto no se parece al 80 % que lo precedió.
Los siete días que dan la razón al no-code
Esos siete días son reales y merecen defenderse. En una semana, una herramienta como Bubble o Softr ofrece pantallas que se encadenan, una base de datos que conserva lo que se introduce y un pago de prueba que funciona. Un desarrollador clásico habría consumido el mismo tiempo instalando su entorno. Para mostrar una idea a un socio o a un primer cliente, esa semana basta, y lo decimos en otro artículo: el prototipo de una noche tiene su lugar. El malentendido empieza cuando esa semana se utiliza como unidad de medida para lo que sigue.
Lo que espera el día 9
El proveedor cita cuatro cosas y todas vuelven a la misma columna del tablero: lo que ocurre cuando un usuario hace algo distinto de lo previsto. Una contraseña olvidada mientras se está creando una cuenta. Una lista vacía el primer día, antes de que exista un solo cliente, que nadie ha diseñado porque nunca se ve en la demostración. Un teclado del teléfono que tapa el campo que hay que rellenar. Una función que parecía garantizada porque existe en todas las aplicaciones del teléfono. Ninguna de estas cuatro cosas aparece en el relato inicial. Las cuatro bloquean la publicación y cada una exige una decisión por tu parte antes de exigir trabajo a alguien. Un usuario que abandona ante una lista vacía no vuelve para explicar por qué.
Por qué el último quinto cuesta más
El 80 % hecho es lo que alguien había descrito: las pantallas, el recorrido principal y la venta. Se construye rápido porque está escrito en alguna parte, aunque sea en una frase. El 20 % restante es lo que nadie describió, y cada punto exige una decisión que la herramienta no puede tomar por ti: qué ve un usuario que aún no tiene datos, qué pasa con un pedido cancelado o quién recibe el mensaje cuando falla un pago. El proveedor cuenta que terminó cobrando ese último quinto en participaciones de capital porque ya no quedaba presupuesto. El presupuesto se había calculado con la velocidad de los siete primeros días y el cliente ya había anunciado una fecha a sus propios clientes.
Una sola regla de acceso puede obligar a reconstruirlo todo
Otro testimonio del mismo foro va más allá (r/nocode, julio de 2026): su autor vio a una agencia reconstruir una aplicación entera de Softr porque un cliente quería permisos de lectura distintos fila por fila, algo que la herramienta no podía hacer. Todo lo demás encajaba. Ese punto no. Una plataforma no-code fija sus límites cuando la eliges y no te encuentras con ellos hasta el sexto mes, ante una petición que parece inocente. La pregunta antes de elegir una herramienta debe centrarse menos en lo que muestra y más en lo que se negará a hacer más adelante.
Lo que cambia un desglose en etapas verificadas
La solución está en el orden del trabajo. En Maestro, Marcel divide el documento de requisitos validado en etapas que se sostienen por sí solas y Félix escribe las pruebas de una etapa antes de que Amélie la construya. Así, un caso límite olvidado se ve durante el desglose, cuando cuesta una frase, en lugar del día 9, cuando cuesta rehacer. El recuento sigue siendo honesto: el número de etapas es visible desde el principio y no cambia a escondidas. Esto no hace gratuito el 20 %; sigue siendo el trabajo más lento del proyecto. Lo hace visible antes de que anuncies una fecha a alguien.
Por dónde empezar
Antes de retomar tu MVP, escribe la lista de lo que nunca se ha descrito: cada pantalla cuando no hay nada que mostrar, cada recorrido que falla (pago rechazado, contraseña perdida, cliente eliminado) y cada permiso de lectura que varía entre usuarios. Cuenta las líneas. Si la lista supera lo que pensabas que faltaba, tu estimación se basaba en la velocidad de los siete primeros días. Rehazla a partir de esta lista y cuenta el tiempo real, no la velocidad del inicio.