Retail investors in India face a specific problem that more data doesn't solve. The market is open from 9:15 AM to 3:30 PM. Most people have jobs. Even those who want to invest actively — who follow markets, read research, join trading groups on Telegram and WhatsApp — can't be in front of a screen when it matters.
The insight: Retail traders don't want more advice. They want reliable execution without constant involvement. The tips and signals industry already existed. What didn't exist was a platform where an expert's strategy could execute automatically in a subscriber's brokerage account — in real time, transparently, with the user's funds staying exactly where they were.
TradingRooms was not a robo-advisor. Not a tips service. A social platform where expert traders ran Rooms, and subscribers auto-traded alongside them.
TradingRooms wasn't a single-user product. It was a three-sided system — and every design decision had to work across all of them simultaneously.
“Users reasoned at the Room level, not the trade level. The product abstracted individual trades into a Room — and that abstraction was the design.”
Users didn't ask “what trades happened today?” They asked “how is my Room performing?” That distinction shaped every screen.
The hardest design constraint wasn't information architecture or two-sided marketplace logic. It was trust. “Automation without loss of control” wasn't a design principle I wrote down — it was a constraint I kept running into.
What that principle meant in practice:
Users can see every trade executed in their account · Users can pause or exit a Room at any time · The brokerage account stays in the user's name — TradingRooms never holds or touches funds · Execution happens at the user's broker, using their existing account
TradingRooms was not a custodian. It was a relay. Expert strategy in → execution at the user's broker out. That architecture wasn't just technically cleaner — it was the trust model.
The automation runs, but the user can see it running.
Users follow specific calls — fine for power users, but requires constant attention and creates no stickiness.
A Room is a container: strategy + creator + subscribers + performance + community. Users subscribe to a Room — and everything inside it follows. Discovery, performance, and trust all operate at Room level, not trade level.
Different brokers had different flows, API setups, TOTP requirements. Users were dropping off because docs weren't specific enough.
When a user selects a broker, a short video showing exactly how to link that broker appears inline — right next to the selection, before they start. Not a redirect. A contextual walkthrough at the exact moment of friction.
Automating real money decisions without user visibility creates a trust cliff: everything feels fine until it doesn't, with no context or recourse.
Every trade is visible. The automation runs, but the user can see it running. Pause and exit controls are always accessible. The system executes; the user stays informed.
Contextual help at the exact moment of highest drop-off.
TradingRooms validated the core thesis: retail traders would delegate execution to experts they trusted, and expert traders would pay to monetise their strategies. Rooms were created, subscriptions activated, trades executed automatically in real brokerage accounts. The system worked.
“The cold-start problem on the creator side, and the trust gap on the user side, were product problems that design alone couldn't close.”
What it also surfaced was a harder problem. Trust at scale requires track record. Track record requires time. An early-stage platform — even a well-designed one — can't manufacture the kind of verified performance history that makes a retail investor comfortable automating their savings. The cold-start problem on the creator side, and the trust gap on the user side, were product problems that design alone couldn't close. Without the distribution to solve both simultaneously, the platform couldn't reach the scale where network effects would have kicked in.
TradingRooms was sunset as part of broader strategic prioritisation within Rain. The three-sided system thinking, the two-sided marketplace instincts, and the “automation with transparency” design principle carried into everything that followed.
To better understand the creator experience, I created a Room on TradingRooms. That wasn't just a test account — I was a creator on the platform I was designing. That dual perspective changed how I thought about the product. Designing the Room creation flow, I knew exactly where the friction was because I'd felt it myself.
The broader lesson: in marketplaces, the designer needs to understand both sides of the transaction at depth. The experience of the Room Creator directly shapes what the Room User sees, trusts, and acts on. Optimising one side in isolation breaks the other.
What I'd do differently: more structured validation of the trust threshold before building. What does it take for a first-time user to hand over trade execution to a stranger on the internet? That's not a UX question — it's a product question. Answering it earlier would have shaped the go-to-market as much as the design.
