qué es este post. una mirada build-in-public a un engagement. un equipo de producto fintech serie b tenía una función de ia que se veía bien en demo y no lograba salir a producción. la reconstruimos como una función de producción en 5 semanas. llegó al 100% de los usuarios, y los tickets de soporte sobre esa función bajaron 60% después del lanzamiento.
el prototipo ya existía. un product manager lo había construido en lovable durante un fin de semana. se veía real. funcionó bien en la demo del all-hands. luego se quedó parado cuatro meses, porque verse real y ser confiable son dos trabajos distintos.
aviso previo al lanzamiento: el cliente está anonimizado. el rollout de 5 semanas y la caída del 60% en tickets son las cifras entregadas del engagement, no proyecciones. no los nombramos porque el contrato dice que no. lo importante aquí es la construcción, no el logo.
#¿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 ia a producción?
empieza por el problema real, no por la ui de la demo. reconstruye la función dentro de tu propio producto con respuestas en streaming, un test suite que revisa las respuestas contra casos ya validados, registro de auditoría y revisión humana donde importa. para este equipo fintech, ese camino tomó 5 semanas y redujo los tickets de la función 60%.
#¿qué construimos en realidad?
no empezamos por el cuadro de chat del prototipo. empezamos por su cola de soporte. los tres tickets de mayor volumen sobre esta función apuntaban todos a lo mismo: los usuarios no podían conseguir una respuesta clara sin escribirle a soporte. así que construimos la función para responder primero esas tres preguntas, dentro de su propio producto y su propio design system, no como un widget pegado encima.
- 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 estancado hasta convertirlo en una función lanzada, con streaming, test suite, registro de auditoría y ux nativa dentro del producto.
we aren't
no pegamos un cuadro de chat genérico encima del producto y lo llamamos función de ia.
#¿por qué los tickets de soporte bajaron 60%?
porque construimos la función al revés, partiendo de los tickets. las tres preguntas que generaban más volumen de soporte son las tres que la función ahora responde dentro del producto, antes de que el usuario tenga que escribirle a alguien. el registro de auditoría nos dice qué preguntas maneja la función y cuáles todavía llegan a una persona. ese mismo registro es cómo supimos que la caída del 60% era real y no una baja estacional. se mide, por tipo de ticket, contra las ocho semanas anteriores al lanzamiento.
el test suite es la razón por la que la caída se sostuvo. antes del lanzamiento, cada cambio corría contra las respuestas ya validadas. una edición de prompt que arreglaba un caso y rompía otros dos se detectaba antes de llegar a un usuario. esa es la diferencia entre una demo que funciona una vez y una función que funciona siempre. los equipos de producto llaman a esto shipping. estamos de acuerdo. más sobre cómo abordamos esto: el trabajo de producto está aquí.
#¿cuánto tardó en salir a producción?
cinco semanas, de prototipo al 100% de los usuarios. la semana uno fue el registro de auditoría y el test suite, porque no puedes mejorar lo que no puedes medir. las semanas dos y tres reconstruyeron las tres respuestas de mayor ticket dentro del producto. la semana cuatro fue la ux del design system y el streaming. la semana cinco fue un rollout por etapas, diez por ciento de los usuarios a la vez, vigilando el registro de auditoría por si algo se les escapaba a las pruebas. sin lanzamiento de big bang. sin reconstrucción de un trimestre completo.
pasó de ser algo que demostrábamos a algo que lanzamos, y la cola de soporte es cómo sabemos que funcionó.
esto es lo que tienen en común la mayoría de nuestros casos de estudio build-in-public. la victoria no es el modelo. son las partes aburridas alrededor: el test suite, el registro de auditoría, los checkpoints de revisión, el rollout que puedes ir viendo. eso es lo que convierte un prototipo en algo que puedes poner frente a cada usuario. si tienes una construcción en v0 o lovable atascada en demo sin camino hacia adelante, esa es exactamente la brecha que cerramos. cuéntanos qué estás construyendo.