There’s a question that stalls Generative UI (GenUI) projects before they start. GenUI uses an LLM to build the user interface, which means every round trip with a user burns tokens, and sooner or later someone is going to look at that and ask: “We’ll burn a bunch of expensive tokens on this. How do we know it will be worth it?”
If you own the planning and implementation of a GenUI experience you need to be able to answer that question. We’ve asked ourselves the same question while building GenUI Kit. At the end of the day, it’s a standard ROI question.
In this post, we’ll talk about how you can address the question head on paired with the tools GenUI kit, our Flutter toolkit for building generative UI, provides to do so.
Start with the goal in mind
Calculating the cost is straightforward. You’re going to get a bill from your cloud provider and they’re going to tell you exactly how many tokens you spent, and you can attribute those costs to your generative experience. But that’s only one half of the equation. What about the revenue side? That’s where you need to think carefully about the goals of your project, what success looks like, and how you would actually track and calculate it.
This doesn’t have to be novel. These are traditional metrics businesses have always cared about. Let’s be concrete: Are you trying to drive more sales? Reduce bounce rate? Increase time on site? Save employee time?
I’ve sat across from enterprise teams who have a mandate to put generative UI somewhere, anywhere, in their organization. While they’ve considered the cost, some haven’t clearly defined what success looks like. Those projects can’t prove they’re worth the investment, because nobody decided up front what the goal is and how to measure it.
Measure it like any other experience
There’s a temptation to argue that generative UI is a new paradigm, we’re still figuring it out, and it shouldn’t be held to the same standard of measurement as everything else. I don’t buy it. I would measure it the exact same way I’d measure any other change: I would line up an A/B test.
Run the static experience against the generative one, same goal, same instrumentation. For ecommerce experiences the target is blunt: what did people spend per user in each arm, and what did each arm cost per user? The goal doesn’t change because the interface generates itself. If the point of the experience is to have people spend money, that is still literally the goal of the whole thing. The only question is how successful each experience actually is.
There’s research showing personalized experiences lead to higher spending, between 10 and 15%. That is an assumption, though. There is no guarantee. The lift is the hypothesis your A/B test exists to check.
Not every GenUI experience will be a winner
MIT’s widely cited NANDA report found 95% of enterprise generative AI pilots never touch the P&L, and Gartner expects over 40% of agentic AI projects to be canceled by 2027, with cost a leading killer.
I build generative UI for a living, so this is the part where I’m supposed to tell you GenUI is the exception. I’m not going to, because I’m confident GenUI experiences will be amongst the corpses too. There are going to be a lot of successful deployments and a lot of unsuccessful ones. That’s why the most important thing is to measure it. I am a software engineer at the end of the day, and I’m genuinely interested in helping teams discover what works and what doesn’t, backed up by real data.
From my perspective, the most common failure mode is the unmeasured internal tool, where the success metric is something fuzzy like “people find it useful.” Maybe folks use it all the time. It’s awesome. However, if it’s costing your team a lot of money to run each month and the actual value is undefined, how would you know it’s worth it? If you aren’t measuring the uplift, in hours saved, in invoices sent, in products sold, in some number a finance team can actually check, it’s going to show up as pure cost.
The second failure mode hides in your averages. For example, say you have power users of an AI product, and those users cost $30 to $35 a month against a $20 price per month subscription. That’s fine as long as the average is significantly under $20. However, if your average usage is $35, you’re simply setting money on fire. When you model this out you need a spending cap, a strategy to drive costs down, or a real story about changing the usage distribution.
One more caveat: your first generative experience is going to get tested against a static experience you’ve spent years honing, so that’s not a fair fight at first, and you’d want to give it a few rounds before you call it. But there does need to be a cut-off point at some point.
You’re in control of the costs
Now that you’ve thought about success, remember that session cost isn’t just handed to you. There are a few different levers you can pull during development to drive costs down before you ship your first GenUI experience.
On the input token side, the levers are the size of your GenUI catalog, the length of your system prompt, and caching strategies. A governed catalog bounds what the model can generate, which keeps hallucination risk and token spend down at the same time. It’s the approach we take in GenUI Kit. On the output side, you choose cheaper models, ask for simpler responses, or both.
Then there’s routing, because not every step of a journey needs the same model. The first few steps of a flow are often really simple questions, so you could route those through a cheaper, faster model and then route the final dashboard through a slower, more expensive one.
Cheaper isn’t automatically better, though. On one financial-planning experience we helped build, the finale was a rich generated dashboard. When I threw cheaper models at it, they produced simple, uninteresting dashboards, and the whole reveal factor wasn’t that useful. The savings weren’t worth what they cost the experience. It becomes an interesting sort of Goldilocks project: the call between quality, speed, and cost, triangulating between those three parameters. I’ve written before about how model choice changes what an experience can be, in our model benchmarking guide for generative UI frameworks.
The other half of this is that you don’t have to guess. GenUI Kit’s sandbox shows the input and output tokens for a complete session. Build the experience, run it end to end, read the meter, and you have a per-session cost you can plug into your cloud provider’s own calculator and project across a year of real traffic. Then the conversation becomes a threshold question: does the lift you can reasonably expect cover the run cost you can already see, or not? I want to be careful with the language here because these are cost estimates or projections. That said, you can and should estimate the price to run your GenUI experience before you ship it to production.
To give this a concrete example, let’s go with round numbers. Put 1,000 users in the static arm and 1,000 in the generative arm. Say the sandbox tells you a complete generative session costs 40 cents, so that arm costs $400 per test cycle. If average spend per user is $200 and the generative arm converts even two points better, you added thousands in revenue against hundreds in cost, so it clears. Reverse those numbers on a low-margin journey and it doesn’t.
Ask a better question
So the question I’d actually ask isn’t “can we afford the tokens,” it’s “which of our journeys clear the threshold.” Ship generative UI where you have a measurable goal, where attribution is clean, and where the lift would cover a run cost you’ve already projected.
You need to have a goal in mind, whether that’s time savings, add-to-cart, reduced bounce rate, or increased time on site. Decide what your success criteria are, decide how you attribute them, and then test that on a generative experience.
E-commerce journeys tend to clear first, because e-commerce is the very best attribution there is. At the end of the day, the question is simply: what did people spend in that experience? Internal tools can clear too, but only if you do the harder work of turning saved hours into dollars before you build.
This is also why I think generative UI has a more direct path to the P&L than most enterprise AI. It can be user-facing, and you can use it to generate user-facing returns, which means the test is real. Put your cards on the table, put it in front of customers against the control, and see whether it has an uplift. Getting there safely takes real production work: a governed catalog that bounds cost and brand risk at once, token metering from your first sandbox session, and a success metric with its attribution designed in before the first generation is served. We cover that in the GenUI approval checklist for production experiences.
Closing thoughts
When we first started working with GenUI, my colleague called generative UI a solution looking for a problem, and I agreed. Neither of us believe that anymore. The more we brainstormed, the more we realized there are a lot of good use cases for it, and the ones worth shipping are the ones you can afford to measure honestly.
If my CFO asked me for the one-sentence version, here it is: we have a really interesting bet to uplift conversion by 10 to 15%, it’s unknown whether that will be worth the cost in the end, so give me a fixed budget to take that bet and test whether it pays off.
A fixed budget, a defined metric, an honest test, and a cut-off point is a business case, not a demo with a bill attached.
If you want to figure out which of your journeys clear the threshold, that’s a working session rather than a sales pitch: map your top three candidate journeys, model their session costs in the GenUI Kit sandbox, and walk out with the numbers your CFO is going to ask for.
