Build vs. buy
You could build this yourself.
With a coding agent, a working bandit prototype is a weekend project. This page is an honest account of what the rest costs, and when building really is the right call.
The easy part
The prototype is real. Take it seriously.
Ask a coding agent for a contextual bandit and you'll have one running by Friday: Thompson sampling on one surface, a table of arms, a reward column. It will work in the demo. That's not an illusion, and it's why building feels closer than it used to. Code stopped being the bottleneck.
Which is exactly why it's worth being precise about what the code was never the hard part of.
The hard parts
What doesn't fit in a weekend.
The bandit is a small fraction of a production decision system. These are the problems the prototype defers, and none of them are secrets. They're just work.
Delayed and rare rewards.
A click arrives in seconds. A purchase takes days, and a churn signal takes months. Attributing those outcomes back to the right decision, across sessions and devices, and learning from them before the quarter ends, is a system of its own. Optimizing clicks because they're easy to measure is how you win engagement and lose revenue.
Statistics under shifting traffic.
A bandit moves traffic toward winners while the experiment is still running. That adaptivity is the point, and it biases every naive average. Getting lift estimates you can trust from adaptively collected data is an active research area, not a library import. Get it wrong and the system confidently ships losers.
The cold start.
A fresh bandit knows nothing. On most surfaces, the traffic needed to learn from scratch takes months to arrive, and every new experiment starts the meter again. Making experiments useful from the first visitors, instead of the ten-thousandth, is a hard modeling problem that the weekend version simply doesn't have an answer to.
Guardrails.
The system puts words, prices, and offers in front of your users without a human in the loop. What enforces your brand voice, your legal constraints, your price floors? An evaluation layer, an approval workflow, and automatic rollback when a variant hurts a metric you care about. You own all of that too.
Yesterday's winners.
What won in March is a fact about March. Seasonality, market shifts, and product changes quietly invalidate concluded experiments, and a system that never re-questions its own conclusions will eventually be confidently wrong. Someone has to notice, and it won't be the system unless you built that as well.
The generation loop.
Continuous optimization needs a continuous supply of candidates worth testing. If AI writes them, you own that pipeline's quality, diversity, and cost at production scale, including the failure mode where the model happily generates twenty variants of the same idea.
The ongoing cost
It's not a build. It's an operation.
Suppose you build all of it. Now the system needs an owner. Reward pipelines break when your event schema changes. Evals drift when models update. A bad variant slips through and someone gets paged. The statistics need re-deriving when you add a surface with different traffic. That owner is one of your strongest engineers, and the role doesn't end, because the system's whole premise is that it never stops.
The case for building is that it saves the cost of a vendor. What it actually trades is your team's time, permanently, for infrastructure your customers never see. That's the same trade this entire category exists to end: the tools were already giving your team more work, and building your own is the most work of all.
What you're buying
The asset isn't the code.
What you buy from Curious isn't a bandit implementation. It's a system that starts informed instead of cold, so results arrive from the first visitors. It's every hard problem above, already handled and continuously maintained. And it's the understanding the system accumulates about your customers: every concluded experiment makes the next one start smarter, which is an asset a homegrown build doesn't have on day one and never has if the build stalls at the prototype.
Teams that could write payments code still buy Stripe, because correctness, compliance, and maintenance are the product. Optimization has the same shape: the algorithm is public, and the operating system around it is the value.
When to build
Sometimes you should build it.
If continuous optimization is your core product, build it. If you operate at the scale of a Netflix or a Booking.com, with traffic that makes every statistical problem easier and a platform team whose actual job is decision systems, build it. Those companies did, and it pays for them.
The honest test: are you funding a team to own this for years, or a hack week to start it? If it's the hack week, the prototype will ship, the follow-through won't, and the decisions you meant to optimize will still be guesses next year.
Spend your engineers where you're different.
Your product is the thing only you can build. This isn't.