Prototipos con IA para clientes de agencia: vender y validar sin prometer lo que no se sostiene

Un prototipo hecho con IA vende mejor que una propuesta en PDF, y ese es justo el riesgo. El cliente ve pantallas que funcionan y asume que el trabajo está casi hecho. Si tu agencia no encuadra esa reunión, acabará firmando una fecha y un precio calculados sobre una demo que no guarda datos, no cobra dinero y no aguanta a diez personas dentro.

Este artículo va de cómo usar estas herramientas a favor: para vender mejor, para validar antes y para llegar al equipo técnico con algo aprovechable. Y de las tres o cuatro frases que no hay que decir nunca en esa reunión.

Qué cambia un prototipo en una venta de agencia

Cambia bastante, y para bien:

• Acorta la discusión sobre el alcance. La gente opina mucho mejor sobre lo que ve. Dos rondas de comentarios sobre un prototipo valen más que seis reuniones sobre un documento.
• Saca a la luz los requisitos escondidos. El cliente ve la pantalla de alta de usuario y suelta: “aquí también hay que poder importar los de la base antigua”. Eso, en un PDF, no sale hasta el mes tres.
• Reduce el coste de decir que no. Prototipar tres ideas y descartar dos es una semana bien invertida. Descartarlas después de firmar cuesta el proyecto.
• Te posiciona distinto. Llegas con algo hecho a una reunión donde el resto lleva diapositivas.

Lo que no cambia es el trabajo que hay debajo. La velocidad que has ganado es la de la primera versión de la interfaz. El modelo de datos, los permisos, las integraciones y la operación siguen costando lo mismo que costaban.

Lo que el prototipo demuestra y lo que no

Esta tabla es, literalmente, la que conviene tener delante en la reunión.

La columna de la izquierda es mucho. Es, de hecho, lo que antes costaba semanas. Pero si el cliente sale de la reunión creyendo que también ha visto la de la derecha, el problema es de la agencia, no del cliente.

Cómo encuadrar la reunión sin bajar el nivel de la venta

No hace falta rebajar nada. Hace falta ser preciso. Tres frases concretas, para decirlas tal cual:

“Esto es un prototipo funcional. Sirve para que acordemos las pantallas y el recorrido antes de construir. No guarda datos reales y no es la versión que se entrega.”

“Lo que ves aquí se ha hecho en dos días. Lo que hay detrás (permisos, integraciones, pagos y puesta en producción) es la mayor parte del proyecto y lo presupuestamos aparte.”

“Antes de darte una fecha necesito saber con qué sistemas tiene que hablar esto y quién tiene que poder ver qué. Eso es lo que mueve el plazo.”

Fíjate en lo que hacen esas tres frases a la vez: no le quitan mérito a lo que has enseñado, dejan claro que queda trabajo y convierten la siguiente conversación en una de requisitos, no de descuento. Un cliente serio agradece esto. Los que no lo agradecen suelen ser los que luego discuten cada factura.

Y una frase que no hay que decir nunca: “esto ya está prácticamente hecho”. Aunque lo parezca. Sobre todo si lo parece.

Las promesas que no se sostienen

Cuatro, por orden de frecuencia:

1. La fecha calculada sobre el prototipo. “Si esto ha salido en dos días, en tres semanas lo tenemos.” No. El prototipo no tenía que conciliar pagos, ni migrar 12.000 contactos, ni cumplir con lo que exige el departamento legal del cliente.
2. El precio cerrado antes de conocer las integraciones. La integración con el sistema que el cliente lleva usando ocho años es casi siempre la partida más cara, y casi nunca se ve en el prototipo.
3. “El cliente podrá seguir editándolo él mismo desde el chat.” Es verdad mientras el proyecto viva dentro de la herramienta. En cuanto el equipo técnico se lleva el repositorio y añade su propia lógica, seguir pidiendo cambios por chat es la vía directa a romper lo que funcionaba. Si prometes esa autonomía, prométela para el contenido, no para el sistema.
4. “Funciona igual con datos reales.” El prototipo funciona con tres filas metidas por ti. Producción son datos duplicados, campos vacíos, nombres con acentos raros y gente pulsando dos veces el botón de pagar.

Hay una que además es técnica y conviene conocer antes de comprometerse: si el proyecto necesita un backend que no sea JavaScript, algunas de estas herramientas lo descartan por diseño. La documentación de tecnologías soportadas de Bolt (consultada en septiembre de 2026), por ejemplo, dice que solo admite backends en JavaScript y que PHP o Python no son compatibles. Prometer una integración con el sistema en PHP del cliente sobre un prototipo hecho ahí es prometerse un rehacer.

Qué validar de verdad con el prototipo

Si vas a invertir dos días en esto, que sirvan para reducir riesgo, no solo para impresionar:

• Lleva el prototipo a quien lo va a usar, no solo a quien lo paga. Las personas de atención al cliente, de almacén o de administración desmontan en quince minutos supuestos que el director daba por buenos.
• Fuerza los casos feos delante del cliente. ¿Qué pasa si este campo llega vacío? ¿Y si el mismo cliente aparece dos veces? Sus respuestas son requisitos, y salen gratis en esta fase.
• Pregunta por el dato, no por la pantalla. “¿De dónde sale este listado hoy?” suele destapar una hoja de cálculo que alguien mantiene a mano y que es, en realidad, el sistema que hay que sustituir.
• Mide algo. Si el prototipo se enseña a usuarios, apunta cuántos completan el recorrido sin ayuda. Eso es validación; lo demás es opinión.

El paso al equipo técnico

Aquí se pierde la mitad del valor del prototipo, casi siempre por lo mismo: se entrega el enlace y nada más. Esto es lo que hay que entregar.

Qué entregar

• El repositorio, con acceso. No una URL de vista previa. El código, en un repositorio al que el equipo técnico pueda entrar. Si la herramienta sincroniza con Git, conéctalo desde el primer día y no el día de la entrega.
• La lista de lo que el prototipo dio por supuesto. Cada pantalla tomó decisiones que nadie discutió: qué campos son obligatorios, qué pasa al borrar, qué ve cada perfil. Escríbelas. Son el núcleo de la especificación.
• El modelo de datos real, con volúmenes. Cuántos registros hay hoy, cuántos entrarán al mes, de dónde vienen y en qué estado. La diferencia entre 200 y 200.000 filas cambia la arquitectura, no el precio.
• Los sistemas con los que hay que integrarse, con documentación y credenciales de pruebas. Si no hay entorno de pruebas, eso ya es un riesgo del proyecto y hay que decirlo antes de firmar.
• Los perfiles de usuario y qué puede ver y hacer cada uno. Esta es la pieza que más se olvida y la que más incidentes provoca. La documentación de la integración de Lovable con Supabase (consultada en septiembre de 2026) lo dice de forma directa: la falta de políticas de permisos a nivel de fila es la forma más habitual de que los datos de una aplicación queden expuestos, y hay que verificarlas a mano antes de publicar.
• El criterio de éxito del cliente. Qué tiene que pasar para que considere que el proyecto ha ido bien. Si no está escrito, se redefine cada mes.

Qué preguntar antes de presupuestar

• ¿Con qué sistemas tiene que hablar esto y quién los administra hoy?
• ¿Hay datos personales? ¿De qué tipo y quién debe poder verlos?
• ¿Se cobra dinero dentro? ¿Con qué pasarela y qué pasa cuando un pago falla?
• ¿Cuántos usuarios y cuántos registros, hoy y dentro de un año?
• ¿Qué hay que migrar y desde dónde? ¿Quién valida que la migración es correcta?
• ¿Quién mantendrá esto después de la entrega? ¿Vosotros, ellos, nadie?
• ¿Qué pasa si el sistema se cae un domingo? ¿Hay compromiso de disponibilidad?
• ¿Hay alguna decisión ya tomada que no se puede cambiar? Proveedor de infraestructura, idioma, normativa del sector.

Las respuestas a estas ocho preguntas son el presupuesto. El prototipo es la portada.

Qué no firmar

• Fecha cerrada calculada sobre el tiempo del prototipo. Si el cliente necesita una fecha, dale la de una primera fase acotada, no la del sistema entero.
• Precio cerrado sin conocer las integraciones. O se investigan antes (y eso también se cobra), o el precio es por fases.
• Mantenimiento incluido “por si acaso”, sin definir. Mantener no es corregir errores gratis para siempre. Define qué entra, cuántas horas y con qué tiempo de respuesta.
• Penalizaciones por caídas sin monitorización acordada. Si te comprometes a disponibilidad, tiene que haber alertas, guardias y alguien que responda. Si no lo hay, no firmes el compromiso.
• Propiedad del código sin decir de qué código. Aclara qué se entrega, en qué repositorio y con qué licencias de terceros. También quién paga las cuentas de las plataformas: las suscripciones de la herramienta, del hosting y de la base de datos tienen dueño y hay que nombrarlo.
• Depender de una sola persona sin contrato que lo cubra. Si todo el proyecto vive en la cabeza de un freelance, el riesgo es tuyo ante el cliente. Ese patrón lo desarrollamos en cuando todo depende de una sola persona.

Errores comunes de agencia con esto

• Enseñar el prototipo sin encuadre y corregir después. El encuadre cuesta treinta segundos al principio y una renegociación al final.
• Tratar el prototipo como entregable. Es una herramienta de conversación. Si se entrega, se entrega con lo de arriba.
• Iterar el prototipo hasta el infinito. Llega un punto en que cada cambio cuesta más que hacerlo bien. Suele coincidir con la primera vez que dices “es que no consigo que haga justo esto”.
• Firmar y buscar después quién lo construye. El orden correcto es al revés: alcance cerrado con el socio técnico y entonces se firma.
• No revisar el código generado antes de basar un presupuesto en él. Lo que hay que mirar está en revisar código generado por IA.
• Olvidar la operación. Copias de seguridad, alertas, accesos, soporte. Lo que hay que tener resuelto antes de abrir al público está en el checklist técnico de lanzamiento.

Cómo se hace el paso bien, en resumen

El prototipo abre la puerta y acorta el alcance. El encuadre protege el presupuesto. Las ocho preguntas convierten una demo en un proyecto presupuestable. Y la entrega al equipo técnico no es un enlace: es repositorio, supuestos escritos, modelo de datos, integraciones, permisos y criterio de éxito.

Hecho así, estas herramientas son un buen negocio para una agencia. Hecho de la otra forma, son la mejor máquina de firmar proyectos que se entregan tarde y con pérdidas.

Dónde encajamos nosotros

En FCG Systems trabajamos con agencias en las dos modalidades. Podemos entrar antes de firmar, para cerrar el alcance técnico y que el presupuesto refleje el trabajo real. Y podemos entrar después, para construir el backend, asegurarlo y mantenerlo mientras la relación con el cliente sigue siendo vuestra: eso es lo que hacemos en marca blanca, dentro del servicio de partner tecnológico, o como proyecto cerrado en software a medida.

Si quieres el contexto de las herramientas antes de elegir, empieza por Lovable vs Bolt vs v0 y por qué es Lovable y hasta dónde llega. El recorrido técnico completo está en de prototipo con IA a producción, y el marco general de trabajar así, en qué es el vibe coding.

Si tienes un prototipo encima de la mesa y una propuesta a punto de salir, cuéntamelo antes de enviarla y te digo qué falta por cerrar.