Hatef.
Blog

Essay

From Trading Systems to Product: What Building a Fintech App Taught Me

Lessons from building a finance education platform — how systems-engineering instincts apply, and sometimes clash with, product thinking.

I spent years building trading systems. Low-latency order execution, real-time risk engines, market data pipelines that couldn't afford to hiccup. The problems were hard, the constraints were unforgiving, and the feedback loop was immediate: either the trade went through or it didn't.

Then I started building a product for humans.

The feedback loop changed completely

In trading systems, correctness is binary. A position either matches the book or it doesn't. A message either arrives within the SLA or it pages someone.

In product, correctness is a spectrum — and the judge is a user who doesn't know your architecture, doesn't care about your latency, and will quietly stop using your app if something feels confusing.

Building the Finance Learning Platform forced me to internalize this. I could ship a perfectly working skill tree with zero bugs and watch users bounce off the onboarding because the first lesson started with too much jargon.

The system worked. The product didn't.

Systems thinking is still useful — but reoriented

The instincts that made me good at trading systems didn't disappear. They just needed recalibration.

Decomposition still matters — but the units are user journeys, not services. I found myself mapping out "what does a first-time user need to feel after five minutes?" the same way I'd map out "what does this message need to contain before it hits the matching engine?"

Failure modes still matter — but now the failure is "user doesn't understand" instead of "packet dropped." The paper trading simulator required more care around surfacing why a simulated trade failed (wrong order type, insufficient buying power, market closed) than the mechanics of simulating it.

Observability still matters — but instead of latency histograms, I'm thinking about where users drop off in the lesson flow, which module has the highest retry rate, where confusion clusters.

The skill tree was harder to design than any distributed system

The most technically complex thing I built in my career is probably a real-time risk aggregation system that had to handle correlated positions across thousands of instruments without falling behind.

The hardest design problem I've worked on is the skill tree for this learning platform.

Not the implementation — the design. What unlocks what? How do you prevent users from hitting a wall while still giving them a sense of progression? How do you make a finance curriculum feel like a game without making finance feel trivial?

These aren't engineering questions. They're product questions. And there's no benchmark to run, no profiler to attach.

What I'd tell past me

Trading systems make you excellent at optimizing within constraints. Product engineering makes you question whether you're optimizing the right thing.

Both skills matter. But product requires a different kind of humility — the willingness to be wrong about what users need, and to build the feedback loops that tell you faster.

I built this platform because I wanted to teach what I knew. I'm still learning how to build something people want to learn from.


This portfolio and platform were built with the help of AI tools, including Claude. The thinking, product decisions, and domain knowledge are mine.