What we learned building trading platforms for Indian retail traders

A large share of our software work has been trading-analytics products for the Indian retail market — option-chain tools, OI dashboards, FII/DII analytics, paper trading, subscription billing. On the surface they're read-heavy data apps. In practice, three problems show up on every one.

1. Entitlement has to be server-side and boring

Every market-data request is proxied through the backend with a service key and a subscription check, so the data vendor never sees end users and access control can't be bypassed from the client. When the product sells on both Razorpay and Apple in-app purchase, the two have to reconcile into one 'days left / is subscribed' answer — including revoking sessions when an Apple subscription lapses and detecting ownership conflicts on restore.

2. Upstream data is never one shape

Provider payloads arrive as objects, as arrays of rows, as column arrays, with lot sizes baked in or not, with CSS classes smuggled into fields. Every analysis screen we ship has a normalisation layer that maps all of it into one clean row model with derived colour buckets for PCR, trend and signal. When the upstream format shifts — and it does — the screen degrades, it doesn't blank.

3. The market clock is a first-class input

• Cache TTLs are shorter during market hours and longer after close, so live users get fresh numbers and off-hours load doesn't hammer the provider.
• Scheduled screeners run on weekday market time — one product runs Gann and demand/supply scans at 15:30 on a 30-second loop.
• A 'trading session' check treats 09:00–15:30 as active and changes what the UI shows outside it.

None of this is visible in a demo. All of it is the difference between a product that works for a week and one that runs for years.