Hacer el prototipo ya no es el problema: el valor se ha movido al tramo siguiente
Parte de la serie sobre tiempo de respuesta a los contactos
Si cualquiera monta algo que funciona en una tarde, lo escaso es lo que viene después: datos reales, casos raros y quién lo mantiene el mes que viene.
Un dato de finales de septiembre de 2026, recogido por TechCrunch: Lovable, una de las plataformas de prototipado con IA, anunció que supera los 600 millones de dólares de ingresos anualizados —lo que facturaría en un año al ritmo de ese mes—, frente a unos 500 en junio. Según la propia empresa, en dos tercios de las del Fortune 500 hay gente usándola, y entre sus clientes están Microsoft, Nvidia y Deutsche Telekom.
Se puede leer como una noticia de inversión. Es más interesante leerla como lo que dice sobre el trabajo: construir algo que funciona ha dejado de ser la parte difícil.
Lo que antes eran semanas de trabajo ahora son unas horas. Y cuando algo pasa de escaso a abundante, el cuello de botella se mueve.
Dónde estaba el cuello de botella y dónde está ahora
Hace tres años, la conversación era: tenemos esta idea, ¿cuánto costaría montar algo para verla? Y la respuesta era semanas de desarrollo antes de saber si la idea servía.
Eso cambió. Hoy se monta algo que funciona en una tarde, se enseña, y se decide con la cosa delante en vez de con una descripción.
Es una mejora real. Lo que no ha cambiado es el tramo siguiente, y ahí sigue costando exactamente lo mismo que antes.
Lo que un prototipo nunca contiene
Un prototipo demuestra que algo es posible. Para eso está, y está bien que lo haga.
Lo que no lleva dentro son cuatro cosas, y las cuatro deciden si alguien lo usa un martes cualquiera:
Los datos de verdad. El prototipo se prueba con tres ejemplos bien escogidos. En producción entra el nombre en mayúsculas, el teléfono con prefijo raro, el campo vacío que nadie previó vacío, el formato que el proveedor cambió sin avisar.
Que alguien se entere cuando falla. Un prototipo que se rompe no pasa nada: lo recargas. Algo en producción que se rompe en silencio un viernes por la tarde deja tres días de trabajo sin hacer y nadie lo descubre hasta el lunes.
Quién puede ver qué. Mientras lo usas tú, la pregunta no existe. En cuanto lo usan cinco personas, hay datos que unos pueden ver y otros no, y eso es una decisión con consecuencias legales, no un detalle técnico.
Quién lo mantiene. El mes que viene alguien pedirá un cambio. Si no está escrito quién se ocupa, el cambio no se hace, y a los tres meses se ha vuelto a hacer a mano «porque aquello no acababa de funcionar».
Ninguna de las cuatro es más programación. Son decisiones. Y es el tramo donde se quedan casi todos los proyectos: sobre esto exactamente va por qué solo el 5 % de las buenas ideas llega a funcionar.
La ventaja que sí es nueva
Prototipar rápido tiene un valor real, pero no es el que se anuncia.
No es «ya no necesitas desarrolladores». Es descartar antes.
Si en dos tardes montas algo, lo pones delante de quien va a usarlo y descubres que no encaja con cómo trabaja de verdad, te has ahorrado el proyecto completo. Eso antes costaba dos meses y un presupuesto gastado.
El error es confundir ya funciona con ya está. Entre esas dos frases están las cuatro cosas de arriba, y no las resuelve ninguna herramienta.
Qué preguntar cuando alguien te trae algo que ya funciona
Cinco preguntas. Se responden en un café y ahorran meses:
- ¿Qué pasa cuando entra un dato que no esperábamos? Si la respuesta es «no debería pasar», va a pasar.
- ¿Quién se enterará de que ha fallado, y cómo?
- ¿Quién puede ver estos datos y quién no?
- ¿Quién lo cambia el mes que viene? Con nombre.
- ¿Qué se hace mientras está caído? Aunque sea «volver a hacerlo a mano», pero escrito.
Si las cinco tienen respuesta, ya no es un prototipo. Si falta alguna, es una demo muy convincente, y conviene saber la diferencia antes de que alguien dependa de ella para trabajar.
Lo que esto significa para una empresa pequeña
Buena noticia: probar ideas es barato ahora. Si tienes una duda sobre cómo organizar algo, se puede montar y mirar en vez de discutirlo en reuniones.
La parte menos cómoda: que sea barato prototipar no hace más barato el tramo final, y ese tramo es el que decide si el trabajo cambia de verdad o si tienes una carpeta de cosas que casi funcionaron.
Si lo que te planteas es montar tú la respuesta automática a tus clientes, hay una lista de diez preguntas para saber si te compensa en automatizar tú mismo o encargarlo.
Nosotros vivimos ahí —es el trabajo de llevar un prototipo a producción—, y por eso el plazo que damos son dos o tres semanas por proceso, no dos días. Lo que ocupa ese tiempo casi nunca es programar: es escribir el proceso —que muchas veces no estaba escrito—, probarlo con lo peor que hay en la base de datos, y dejarlo funcionando sin que dependa de quien lo construyó.
Preguntas frecuentes
¿Sirven las herramientas de prototipado con IA para producción?
Para prototipar y validar una idea, muy bien. Para producción depende de lo que haya detrás: quién responde cuando falla, cómo se controla el acceso a los datos, qué pasa con los casos que nadie previó y quién lo mantiene el mes que viene. Eso no lo resuelve la herramienta, lo resuelve alguien que se ocupe.
El criterio práctico: si otra persona tiene que depender de ello para trabajar, ya no es un prototipo y necesita las respuestas de arriba.
¿Qué falta exactamente entre un prototipo y algo en producción?
Cuatro cosas que no aparecen en una demo: manejar los datos incompletos y los casos raros, avisar a alguien cuando falla, controlar quién puede ver qué, y tener dueño para el mantenimiento. Ninguna es más código; todas son decisiones que hay que tomar.
¿Entonces prototipar rápido no aporta nada?
Aporta mucho, pero en otra cosa: en descartar antes. Si en dos tardes se ve que la idea no encaja con cómo trabaja la gente, te has ahorrado el proyecto completo. El error es confundir «ya funciona» con «ya está».
¿Cuánto se tarda en llevar algo de prototipo a uso real?
Para un proceso bien delimitado, dos o tres semanas: describirlo, construirlo, probarlo con datos reales y dejarlo funcionando con alguien mirando. Lo que alarga ese plazo casi nunca es la programación, es descubrir a mitad que el proceso no estaba escrito.
Si tienes algo montado que funciona y no se usa, el diagnóstico gratuito es media hora mirando qué falta exactamente para que funcione sin nadie encima. Y si lo que falla es la entrada de contactos, en esa media hora medimos cuánto tardas hoy en dar la primera respuesta, con la hora delante.
Lo que hacemos con eso está en la página del sistema de respuesta a los contactos: primera respuesta con contenido en menos de 60 segundos a cualquier hora, la pregunta que falta hecha, y el aviso al comercial que le toca con el contexto preparado. Sin tarifa publicada: el alcance y el importe se cierran por escrito después del diagnóstico.