Software Engineer · SDE-2
B.01 / Builds

Valo.club

Co-Founder · CTO · Fintech / Investing

From an idea to a product used by around 2,000 people.

I co-founded Valo and built it from the ground up — the product decisions, the design, the frontend, the backend, the integrations and the infrastructure it ran on.

  1. Idea
  2. Product
  3. Real users
  4. ~2,000 users
  5. Regulatory constraint
  6. Shutdown
02The idea

It started with a simple question.

I wanted to build something around investing that people would actually use.

Most investing apps assume you already know what you’re doing. We wanted to make it easier to stay with it — see everything you own in one place, learn as you go, and get rewarded for building good habits.

We started with an idea and eventually turned it into a real product.

03What we built

One consumer product, several systems underneath.

Valo combined broker connections, portfolio tracking, market data, financial content and a rewards system into one consumer product.

  1. 01

    Broker connections

    Connect an existing broker account instead of opening a new one.

  2. 02

    Portfolio

    Holdings, positions, funds and orders, combined across connected brokers.

  3. 03

    Market data

    Live prices, market status, indices, gainers and losers.

  4. 04

    Learning & news

    Financial news and learning content inside the product.

  5. 05

    Rewards

    Valo points, login streaks, rewards, coupons and referrals.

  6. 06

    Community

    Posts and discussion around the market.

V.01 / Valo.clubOverview
Valo.club overview screen: market ticker, balance overview, rewards and financial news
Product design · Figma
Overview — ticker, balances, rewards, news
V.02 / Valo.clubLearn
Valo.club Learn Finance screen with lesson progress and recommended videos
Product design · Figma
Learn finance
V.03 / Valo.clubCommunity
Valo.club community feed with posts and trending topics
Product design · Figma
Community
04Engineering problems

The problems underneath the product.

Most of the interesting engineering in Valo came from connecting to systems we didn’t control — brokers, market data — and making them behave like one product.

P.01

Making different brokers feel like one product

Overview

Users connected the broker accounts they already had. Valo integrated with brokers including Fyers and Upstox.

Problem

Every broker had its own authentication flow, its own tokens and its own API for holdings, positions, funds and orders. If those differences leaked into the product, every screen would need to know which broker it was talking to.

Approach

Each broker sat behind its own integration — handling its OAuth flow, storing and using its tokens, and calling its APIs — so the rest of Valo could ask for holdings or orders without caring where they came from.

  1. Connect broker
  2. OAuth
  3. Broker token
  4. Broker API
  5. Valo
Result

Adding a broker meant writing one more integration, not changing the product around it.

P.01 / Valo.clubAdd brokers
Valo.club settings screen with the Add Brokers panel showing Upstox and Zerodha
Product design · Figma
P.02

Combining portfolios across broker accounts

Overview

A user could connect more than one broker account and expect to see one portfolio.

Problem

Each broker returned portfolio data in its own shape. The same security could appear in two accounts with different quantities and different average prices.

Approach

Normalized the data before it reached the rest of the application, then grouped holdings by security — summing quantities, computing a weighted cost basis across accounts, and deriving P/L from the combined position.

  1. Broker A holdings
  2. Broker B holdings
  3. Normalize
  4. Group by security
  5. Weighted cost · quantity · P/L
Result

Users saw one portfolio, not a list of broker accounts.

P.02 / Valo.clubPortfolio
Valo.club portfolio screen with holdings, returns and recent transactions
Product design · Figma
P.03

Handling real-time market data

Overview

Prices across the product — the ticker, holdings, P/L — needed to move with the market.

Problem

Live data meant holding a WebSocket connection open: authenticating it, subscribing to the right symbols, and cleaning up subscriptions when they were no longer needed, so connections and subscriptions didn’t pile up.

Approach

Managed the stream as a lifecycle — authenticate, subscribe to the symbols in view, pass ticks into the application, and unsubscribe and close when they were no longer needed.

  1. Authenticate
  2. Connect
  3. Subscribe symbols
  4. Ticks → app
  5. Unsubscribe · close
Result

Prices stayed live without the connection becoming something the rest of the product had to think about.

P.03 / Valo.clubLive ticker
Valo.club overview screen with a live market ticker across the top
Product design · Figma
P.04

Building the rewards and redemption flow

Overview

Rewards were the core of the product: points for activity, streaks for coming back, and rewards and coupons to spend them on.

Problem

Points behave like a balance. Earning, streak tracking, referrals and redemption all had to agree on how many points a user had, and a redemption couldn’t be granted twice or leave the balance wrong.

Approach

Modelled it as one flow from activity to redemption, with redemption treated as a single operation that checks the balance, deducts points and issues the reward together.

  1. Login activity
  2. Streak
  3. Points
  4. Reward
  5. Redemption
Result

The rewards system worked as a product feature — which is also why it mattered so much when the rules around it changed.

P.04 / Valo.clubRewards
Valo.club rewards screen with a seven-day streak, tier summary and redeemable rewards
Product design · Figma
05Architecture

A simplified view of the system.

Conceptual · simplified
A.01 / Valo.clubSystem
USERVALO WEB / APPAPIVALO BACKENDAUTHPORTFOLIOMARKET DATAREWARDSNEWSBROKERSBROKER APISMARKET DATA STREAMCONCEPTUAL · SIMPLIFIED
Conceptual representation · simplified

The product talked to one backend. The backend did the work of talking to everyone else — brokers for accounts and orders, a market-data stream for prices.

06Building it from zero

I wasn’t implementing tickets.

There was no backlog to pick from. Every part of Valo started as a conversation about what it should be, and then someone had to build it. Usually that was me.

  1. 01Deciding what to build
  2. 02Figuring out how it should work
  3. 03Designing the product
  4. 04Building the frontend
  5. 05Building backend services
  6. 06Connecting external systems
  7. 07Deploying it
  8. 08Fixing problems after launch
07 — Real users
~2,000Users

That number mattered to me because it meant the product had moved beyond being something we built for ourselves.

08Why we shut it down

When the problem stopped being technical.

We reached around 2,000 users before the regulatory environment around stock-market gaming and rewards changed. The direction we had built around was no longer practical, so we decided to shut the product down.

Nothing was broken. The integrations worked, people were using it. But a product built around rewards for investing activity depended on rules outside our control, and once those rules moved, the honest decision was to stop.

09What I learned

What I took from it.

  1. 01

    Building the product is only part of it

    You can get the engineering right and still not have a viable product.

  2. 02

    Integrations make you think in systems

    Once you depend on someone else’s API, you design around what they do, not what you wish they did.

  3. 03

    Real users find what testing doesn’t

    Real accounts and real money surface cases no test environment had.

  4. 04

    Sometimes the right call is to stop

    Shutting it down was a product decision, made with the same care as building it.

← Back toBuildsNext build →Interpract