Build the reason to come back before the reason to pay

I am the only product manager at BitaSei, a platform that teaches people to trade forex and crypto before they risk real money. It combines structured courses, a paper trading simulator, a trade journal, pattern recognition and an AI tutor. We passed 20,000 signups within a year.

Real-time notifications for trading signals and live classes now account for about 70% of engagement. Specifying that system changed how I think about the order of work in a subscription product.

Value that expires

Trading signals and live classes are time-sensitive. A late alert can mean a learner misses the event it was meant to support.

For these experiences, delivery timing is part of the product’s value. I specified notifications around reaching learners when the event was relevant.

Most products contain something like this: a thing whose value depends on timing. A price that moved, a seat that opened, a reply from a colleague. It is worth finding early, because it decides what users come back for.

The order matters

BitaSei is free to start. The first level of courses needs no card. The business earns only when a learner upgrades to a paid tier and then stays. That gives three jobs, and I think they have to be done in this order.

1. Give people a reason to return. Without it, nothing downstream works.
2. Remove the exits from the path to paying.
3. Give people a reason to stay paid for longer.

It is tempting to start with the second, because checkout is measurable and close to revenue. But a smooth checkout does nothing for someone who has stopped opening the app.

Removing the exits

The payment journey was the next constraint. I tracked activation, conversion and retention in SQL, and used funnel and billing data to find where people dropped out.

A payment journey has more exits than it appears to. I mapped onboarding, authentication and payment end to end before engineering built them, with the failure and recovery paths written down. Then I owned the subscription layer through the Paystack API.

• The upgrade itself: a learner chooses a paid tier and pays by card.
• A failed payment: the learner needs to know, and needs a way to fix it.
• A retry: one failed charge should not end a subscription.
• A renewal: the subscription continues without the learner doing anything.
• Recovering access: a learner who is locked out gets back in without contacting support.

The goal was a journey a learner could complete alone: sign up, verify, pay and recover access, with no support ticket. After those changes, free-to-paid conversion doubled.

I learned to prioritise the fixes that moved conversion, which were not always the fixes that were easiest to argue for. The data is what settled those arguments.

Staying paid

The third job is retention. I added a quarterly option alongside monthly billing to support learners who wanted a longer subscription period. That was a retention decision; it is separate from the measured improvement in conversion.

Retention is easier to design for once you know why people come back at all.

Trust comes before all of it

There is a step before the three jobs. People will not return to a product they do not trust, and in a trading product, trust lives in the numbers on screen.

For the TradingView integration, which provides live price feeds and charting, I worked with engineers on data flows, refresh behaviour, latency, and what the app shows when a feed is delayed, stale or fails. A wrong price is worse than no price. Those edge cases decide whether users believe what they are looking at.

What we chose not to build

The hardest decision was keeping a live trading terminal and links to existing brokers out of scope. It would have let learners place real trades in the same place they were learning.

I kept it out because the product's job is to make someone a better trader before they risk money. Practice runs on a paper account with live prices. A terminal would have pulled a team of eight towards execution and away from teaching. The cost was real: learners who wanted to trade for real had to do it elsewhere.

The questions I ask now

1. What in this product is time-sensitive?
2. Does the user hear about it at the right moment?
3. Can they trust what they see when they arrive?
4. Is the path to paying free of dead ends?
5. Does the plan they pay for match how long the value takes to arrive?

I prototype answers to these in v0 and Lovable and test them with users before any engineering time is committed. It keeps rework down, and it means the backlog holds things users have already reacted to.