OKX · Recurring Buy
Rebuilding Recurring Buy around what users would actually delegate
How a 5% completion rate revealed a delegation problem, not a friction problem. Users were happy to outsource repetition — outsourcing judgment was a different matter entirely. That distinction shaped three versions of the product.
- Role
- Lead Product Designer
- Company
- OKX
- Duration
- Dec 2024 – present · V1–V3
- Platform
- iOS · Android

5×
recurring-buy volume after V2*
+40%
active plans after six months*
3
versions shipped across all regions*
* Measured against the pre-V2 baseline. Volume = recurring buy purchase volume. Active plans = plans with at least one successful execution in the trailing 30 days. Sustained through quarter-end and re-checked at six months.
Diagnosing the 5% completion rate
The symptom looked familiar. People discovered the feature. Opened the flow. Dropped. Most product teams would call that friction: too many steps, too many decisions, too much commitment. We were close to doing exactly that.
The data told a different story. When I broke the funnel apart, 5% completion stopped behaving like one problem. It was three different failures hiding behind the same number.
Three failures hiding behind one metric
Users didn't trust the system yet
A recurring plan isn't a one-time purchase. A purchase ends. A plan keeps making decisions after the user leaves. At launch we were asking people to schedule future purchases before the system had earned that. The commitment felt larger than the interface let on.
Users couldn't invest the way they normally would
Many users wanted to fund recurring purchases using ACH and stablecoins. Neither existed in V1. This wasn't a UX problem — it was an infrastructure problem. Recognizing that early kept us from trying to patch missing payment rails with better screens.
Users couldn't tell whether a plan was working
The product went quiet after setup. Users could see a plan existed, but not whether it was healthy, whether the next purchase would execute, or how to adjust without starting over. When money is involved, silence reads as risk.
The real product starts after setup
Creating a plan takes minutes. Owning one takes months. The real experience starts after setup: when the market moves, a payment fails, a card expires, or a user changes their mind. That's where trust actually gets tested, and where control becomes visible.
Can I see what the system is doing? Can I change it without losing context? Can I tell if it's working? Those questions mattered far more than shaving another step off setup.
Less effort, same control
The principle I set for V2: remove repetitive effort, preserve judgment. Not maximum automation — the right amount of it. People wanted help executing their investing strategy. They didn't want the product replacing it. In parallel, we closed the infrastructure gap behind failure two — ACH and stablecoin funding shipped alongside V2, so better screens weren't papering over missing rails.
Recurring buying became part of buying
We stopped treating recurrence as a separate product. Instead, it became a choice inside the buy flow people already used. Buy once, or buy on a schedule. That's it. The decision got smaller. It also dissolved the funnel we’d been measuring — once recurrence became a choice inside an existing flow, a standalone “completion rate” stopped existing; volume and active plans became the honest scoreboard.
Plans became easier to understand
The redesigned plan view answered the first question users actually had: “Is this working?” Average entry price. Current price. Total invested. Returns. Next execution. Visible at a glance.
Failures became impossible to miss
V1 let plans fail quietly. V2 didn't. Low-balance warnings surfaced sooner. Repeated failures paused plans automatically. Removing a payment method previewed future impact before you confirmed anything. Recovery stopped feeling like detective work.
Automation became accountable
We surfaced recurring purchases in the same places users already tracked their money: Portfolio, Activity, Transaction history. Hidden automation feels suspicious. Automation that shows up in public feels like it's working for you.
Why we didn't build passive yield
The obvious next step after V2 was passive yield. A competitor had it. The business story was easy: idle cash earning something while waiting for the next purchase. Before we built it, we tested the assumption underneath it — did users actually want us making more decisions on their behalf?
I designed the survey myself and clustered the open-ended responses with an LLM. Passive yield barely registered. What users kept asking for was more control over execution. One comment captured the pattern: “Let me decide the rule. Then do the repetitive part for me.”
“Let me decide the rule. Then do the repetitive part for me.”
Why V3 became price-range buying
That changed the roadmap — I made the case for it. Instead of more automation, we gave users a better way to express intent. They defined a price range; the system executed purchases only inside it, handling all the monitoring in the background. The user kept the rule.

V3 shipped latest in the window, so its adoption numbers are still maturing — and the result I trust most didn't show up during launch week anyway. It showed up during the first real market correction: one-time buying dropped, recurring buying held. It’s also the cleanest control I have on the growth numbers above: if 5× volume had been bull-market beta, both lines would have moved together. That was the original promise finally showing up in production — the system staying consistent when emotions weren't.
What changed my thinking
Setup isn't the product
Setup is the sales pitch. The relationship starts afterward. We'd invested heavily in onboarding and underestimated ownership. The redesign reversed that balance.
Minimal isn't always transparent
A sparse interface looks elegant in review. When money is moving, users want less decoration and more evidence. Visibility beats minimalism.
The diagnosis was the design work
We thought we were solving a conversion problem. We were actually solving a delegation problem. People didn't want the product to invest for them — they wanted it to make consistency easier.