Building a recurring buy system users could trust over time
V1 shipped quickly and underperformed. Fixing it took more than simplifying the flow. We had to separate setup friction, payment infrastructure, and long-term trust in the system itself. Later, user research redirected V3 away from passive yield and toward conditional execution control.
What shipped across those three versions wasn’t just a cleaner DCA experience. It became a more reliable execution system for users who already knew what they were trying to do.
V1 plan detail · V2 redesigned plan detail · V3 range DCA
Crypto’s timing problem
Most crypto users on OKX were used to active trading behavior: monitor price, wait, buy manually. Recurring buy asked them to hand part of that control to the system.
That changed the design problem completely.
Dollar-cost averaging already existed as a strategy. The challenge wasn’t teaching users what DCA was. It was convincing them the system would behave predictably over time.
Early on, we treated recurring buy like a transaction flow. Users experienced it as a long-running system.
That difference shaped every version that followed.
Three versions. Three different problems.
We didn’t plan to redesign recurring buy twice. The product kept exposing gaps in our assumptions.
V1 launched quickly with core DCA functionality. Adoption was weak. The diagnosis showed the problem wasn’t singular: setup friction, missing payment infrastructure, and weak lifecycle management were all contributing.
V2 addressed those operational gaps directly.
Then V3 shifted the product again. Product leadership initially proposed a competitor-inspired passive yield feature. User research pointed somewhere else: users wanted tighter execution control, not more passive behavior.
- fixed intervals
- basic plan detail
- order history
- asset detail page entry point
Recurring buy touched trading, asset, and portfolio surfaces, but no team fully owned the lifecycle experience. Shipping V1 required alignment across all three.
- users hit friction before committing
- preferred funding methods were missing
- plans became difficult to manage once created
V2 reduced setup friction, added ACH and stablecoin support, redesigned plan management, and introduced proactive intervention logic for payment failures and low balances.
Instead of increasing passivity, we introduced price-range DCA:
- users define a buy range
- orders execute only inside that range
- execution history remains visible and traceable
At launch, no major competitor offered this model.
5% conversion forced a deeper look
V1 had awareness. Users clicked recurring buy entry points regularly. The problem came after interest.
The diagnosis exposed three separate failures.
01 — Setup friction arrived too early
Users hit setup friction before they had enough confidence to commit to automation.
Recurring buy introduced:
- frequency selection
- funding decisions
- execution timing
- ongoing commitment
Too much configuration appeared before users trusted the system.
The setup flow treated recurring buy like a separate product instead of an extension of an existing buy action.
02 — Funding support didn’t match real behavior
Users preferred ACH and stablecoins for recurring purchases, but those methods were unavailable in V1.
This wasn’t a UI issue. It was infrastructure mismatch.
Users already had established funding behavior on the platform. Recurring buy ignored it.
03 — Users could create plans, but not really manage them
The V1 plan page showed:
- order history
- pause
- cancel
That was essentially it.
Users couldn’t:
- edit plans cleanly
- understand performance
- recover from failed payments easily
- understand plan health
Once a plan was created, the product gave users very little visibility into whether the strategy was actually working.
I initially underestimated how much trust depends on lifecycle management.
That diagnosis became the real product work.
Automation changes the relationship between user and product
A failed market order frustrates users once. A failed automated system damages trust every time it repeats. That shifted the design priorities from transaction completion to long-term reliability and visibility.
Decision 1 — Frequency became part of the buy flow
V1 treated recurring buy like a separate workflow.
V2 integrated recurring frequency directly into the existing buy experience through a lightweight selector:
- one time
- daily
- weekly
- biweekly
- monthly
Users were already trying to buy an asset. Frequency became another purchase parameter instead of a new product flow.
Decision 2 — Plan management became a core product surface
We redesigned the plan detail page around ongoing visibility:
- average entry price
- current market price
- total invested
- cumulative returns
- next execution date
Users could also edit:
- frequency
- amount
- payment method
- execution timing
without deleting plans or losing historical context.
That changed recurring buy from a static setup flow into an ongoing management system.
Decision 3 — The system intervened before users lost trust
V1 failed too quietly.
Plans could stop executing without users fully understanding:
- why it happened
- how long it had been failing
- what action would recover it
We added intervention logic:
- automatic pause after repeated failures
- low balance warnings
- impacted order visibility before payment removal
- direct recovery paths
The goal wasn’t just prevention. It was legibility.
Users needed to understand system behavior.
Decision 4 — Recurring buy became visible across the platform
V1 hid recurring buy behind a single entry point.
V2 integrated plans into:
- portfolio surfaces
- activity feeds
- transaction history
Recurring orders appeared alongside manual trades instead of feeling isolated from the rest of the platform.
That visibility reinforced that recurring buy was part of normal investing behavior, not a niche automation feature.
The research changed the roadmap
After V2 improved adoption and volume, the next proposal focused on passive yield between purchases, similar to competitor products.
The assumption was straightforward: users wanted passive returns while waiting for recurring execution.
The research suggested something else.
Instead of debating assumptions in review meetings, I ran a survey with active recurring buy users.
Survey findings
[YOUR DATA: insert actual percentages and sample size]
- • Passive yield was not a top priority
- • Many users already understood DCA strategy intentionally
- • The strongest request was tighter execution control
- • Users wanted more predictability around execution conditions
N=[sample size], [month/year]
What changed
The research showed users already had investing intent and strategy.
What they wanted was better execution infrastructure.
That shifted V3 away from passive yield and toward conditional execution.
What shipped instead
Price-range DCA:
- users define a buy range
- recurring orders execute only within that band
- execution history remains visible afterward
The interaction stayed simple, but the strategy became more flexible.
Simple doesn’t mean entry-level
Crypto products often equate sophistication with density:
- more indicators
- more controls
- more settings
- more charts
Our users didn’t need help understanding strategy.
Many were already using DCA intentionally before recurring buy existed. What they lacked was a reliable way to execute that strategy over time.
That changed how we approached simplicity.
We removed unnecessary interface complexity while increasing system capability underneath:
| Version | Capability |
|---|---|
| V1 | Interval automation |
| V2 | Lifecycle visibility and control |
| V3 | Conditional execution through price ranges |
The product became more capable each release without becoming harder to understand.
Composable execution logic
V3 showed users wanted more conditional control, not necessarily more automation.
The next step is likely composable execution logic:
- recurring buy inside price bands
- portfolio allocation thresholds
- market condition triggers
- multiple execution conditions combined together
The challenge is keeping those systems understandable.
One condition is easy to reason about. Five conditions can become opaque very quickly.
That’s the next design problem I started discussing with PM after V3 shipped.
Results
Reflection
I under-scoped lifecycle management in V1
We focused heavily on setup and underestimated how much trust depended on recovery states:
- failed payments
- removed funding methods
- paused plans
- editability
- execution visibility
Silent failures damaged trust faster than setup friction did.
I mistook minimalism for transparency
The V1 plan page felt intentionally lightweight during design reviews.
Users experienced it differently.
Without performance visibility or meaningful controls, the product felt incomplete once plans were active.
The diagnosis mattered more than the redesign
Low adoption initially looked like a UX simplification problem.
It wasn’t.
The product had:
- funnel friction
- infrastructure mismatch
- weak lifecycle trust
Each required a different response.
Separating those problems correctly ended up being more important than any single screen redesign.