what this post is. a build-in-public look at one engagement. a series b fintech product team had an ai feature that demoed well and would not ship. we rebuilt it into a production feature in 5 weeks. it went to 100% of users, and support tickets on that feature dropped 60% after launch.
the prototype already existed. a product manager had built it in lovable over a weekend. it looked real. it demoed well in the all-hands. then it sat for four months, because looking real and being reliable are two different jobs.
pre-launch disclosure: the client is anonymized. the 5-week rollout and the 60% ticket drop are the delivered engagement figures, not projections. we don't name them because the contract says not to. the build is the point here, not the logo.
#why does a good prototype stall before production?
because the prototype answers a different question than production does. the prototype proves the idea can work once, on a clean input, with the founder driving. production has to work on the messy input, at 2am, with no one watching, and be defensible when a customer disputes what the feature told them. that gap is where most v0 and lovable builds die. not because the idea was wrong. because there was no path from demo to the thing you can put your name on.
how do you take an ai prototype to production?
start from the real problem, not the demo ui. rebuild the feature inside your own product with streaming responses, a test suite that checks answers against known-good cases, audit logging, and human review where it matters. for this fintech team that path took 5 weeks and cut feature tickets 60%.
#what did we actually build?
we did not start from the chat box in the prototype. we started from their support queue. the three highest-volume tickets on this feature all pointed at the same thing: users could not get a clear answer without emailing support. so we built the feature to answer those three questions first, inside their own product and their own design system, not a bolted-on widget.
- streaming responses so the feature feels immediate instead of a spinner. the answer types out as it forms.
- a test suite that runs the feature against known-good answers on every change, so a tweak to one prompt cannot quietly break another case.
- audit logging on every response, so when a customer disputes what the feature said, support can pull the exact input and output.
- in-product ux built inside their design system, so it reads as part of the product, not a chat window someone glued on.
we are
we rebuilt a stalled prototype into a shipped feature with streaming, a test suite, audit logging, and native in-product ux.
we aren't
we did not drop a generic chat box on top of the product and call it an ai feature.
#why did support tickets drop 60%?
because we built the feature backward from the tickets. the three questions that drove the most support volume were the three the feature now answers in-product, before a user has to email anyone. the audit log tells us which questions the feature handles and which still reach a human. that same log is how we knew the 60% drop was real and not a seasonal dip. it is measured, per-ticket-type, against the eight weeks before launch.
the test suite is the reason the drop held. before launch, every change ran against the known-good answers. a prompt edit that fixed one case and broke two others got caught before it reached a user. that is the difference between a demo that works once and a feature that works every time. product teams call this shipping. we agree. more on how we approach product work is here.
#how long did it take to ship?
five weeks, prototype to 100% of users. week one was the audit log and the test suite, because you cannot improve what you cannot measure. weeks two and three rebuilt the three top-ticket answers inside the product. week four was the design-system ux and the streaming. week five was a staged rollout, ten percent of users at a time, watching the audit log for anything the tests missed. no big-bang launch. no quarter-long rebuild.
it went from a thing we demoed to a thing we shipped, and the support queue is how we know it worked.
this is what most of our build-in-public case studies have in common. the win is not the model. it is the boring parts around it: the test suite, the audit log, the review gates, the rollout you can watch. that is what turns a prototype into something you can put in front of every user. if you have a v0 or lovable build sitting at demo with no path forward, that is exactly the gap we close. tell us what you're building.