De qué trata este artículo. Un ejemplo práctico ilustrativo, no un resultado de cliente. El equipo fintech, su producto y cada cifra son supuestos. Muestra lo que hace falta para convertir un prototipo de AI que luce bien en una demo en una funcionalidad que puedas poner delante de todos los usuarios.
Supón un equipo de producto fintech en serie b. Un product manager construyó un prototipo de una funcionalidad de AI en lovable durante un fin de semana. Parece real y quedó bien en la reunión general. Luego se queda parado, porque parecer real y ser fiable son dos trabajos distintos.
sobre este ejemplo: el equipo es genérico y no hay ningún cliente detrás. Nada de lo que aparece aquí es un resultado entregado ni una proyección. Lo importante es el diseño, no el logotipo.
#¿por qué un buen prototipo se estanca antes de producción?
Porque el prototipo responde una pregunta distinta a la que responde producción. El prototipo demuestra que la idea puede funcionar una vez, con un input limpio, con el founder manejando todo. Producción tiene que funcionar con el input desordenado, a las 2am, sin nadie mirando, y ser defendible cuando un cliente cuestiona lo que la función le dijo. En esa brecha mueren la mayoría de las construcciones en v0 y lovable. No porque la idea estuviera mal. Porque no había un camino de la demo a algo con tu nombre encima.
¿cómo se lleva un prototipo de AI a producción?
Empieza por el problema real, no por la interfaz de la demo. Reconstruye la funcionalidad dentro de tu propio producto con respuestas en streaming, un conjunto de pruebas que compare las respuestas con casos buenos conocidos, registro de auditoría y revisión humana donde importe. Después mide los tickets de soporte sobre la funcionalidad antes y después.
#¿qué incluye el diseño de producción?
No empieces por el cuadro de chat del prototipo. Empieza por la cola de soporte. Supón que los tres tickets de mayor volumen sobre esta funcionalidad apuntan a lo mismo: los usuarios no consiguen una respuesta clara sin escribir a soporte. Construye la funcionalidad para responder primero esas tres preguntas, dentro del producto y del sistema de diseño del propio equipo, no como un widget pegado.
- respuestas en streaming para que la función se sienta inmediata en vez de mostrar un spinner. La respuesta se va escribiendo a medida que se forma.
- un test suite que corre la función contra respuestas ya validadas en cada cambio, para que un ajuste en un prompt no rompa otro caso sin que nadie lo note.
- registro de auditoría en cada respuesta, para que cuando un cliente cuestione lo que dijo la función, soporte pueda sacar el input y el output exactos.
- UX dentro del producto construida dentro de su design system, para que se lea como parte del producto, no como una ventana de chat pegada encima.
We are
Reconstruimos un prototipo atascado en una funcionalidad lanzada, con streaming, conjunto de pruebas, registro de auditoría y UX nativa dentro del producto.
We aren't
No ponemos un cuadro de chat genérico encima del producto y lo llamamos funcionalidad de AI.
#¿cómo sabrías que la funcionalidad reduce los tickets de soporte?
Construye la funcionalidad a partir de los tickets. Las preguntas que generan más volumen de soporte son las que la funcionalidad responde dentro del producto, antes de que nadie tenga que escribir. El registro de auditoría muestra qué preguntas resuelve y cuáles siguen llegando a una persona. Ese mismo registro ayuda a distinguir una caída real de un bajón estacional: compara el volumen de cada tipo de ticket con una ventana de referencia anterior al lanzamiento.
El conjunto de pruebas es lo que hace que cualquier mejora se sostenga. Antes del lanzamiento, cada cambio se ejecuta contra las respuestas buenas conocidas. Una edición de prompt que arregla un caso y rompe otros dos se detecta antes de que llegue a un usuario. Esa es la diferencia entre una demo que funciona una vez y una funcionalidad que funciona siempre. Los equipos de producto lo llaman lanzar. Nosotros también. Más sobre cómo enfocamos el trabajo de producto, aquí.
#¿en qué orden se construye?
Primero el registro de auditoría y el conjunto de pruebas, porque no puedes mejorar lo que no puedes medir. Luego reconstruir dentro del producto las respuestas de los tickets principales. Después la UX del sistema de diseño y el streaming. Por último, un despliegue escalonado a una parte creciente de usuarios, vigilando el registro de auditoría por si algo se escapó a las pruebas. Sin lanzamiento de golpe.
La prueba que aplicar: debe pasar de algo que demostraste a algo que lanzaste, y la cola de soporte es como sabes que funcionó.
Esto es lo que tienen en común nuestros ejemplos prácticos. Lo importante no es el modelo. Son las partes aburridas que lo rodean: el conjunto de pruebas, el registro de auditoría, las puertas de revisión, el despliegue que puedes vigilar. Eso es lo que convierte un prototipo en algo que puedes poner delante de todos los usuarios. Si tienes una versión v0 o lovable atascada en la demo sin camino hacia delante, es justo la brecha que cerramos. cuéntanos qué estás construyendo.
