Overview
My tenure at Sapphire Broking had two distinct phases that together gave me one of the most well-rounded engineering experiences of my career.
I joined as Lead Frontend Developer, owning the entire frontend layer of a production financial platform. After demonstrating strong technical judgment and a desire to go deeper into the system, I migrated to the backend team — picking up Go and working directly on high-performance APIs and exchange integrations.
This progression — from owning the frontend completely to contributing across the full stack — is something I'm genuinely proud of.
Phase 1: Lead Frontend Developer
As the lead on the frontend team, I owned the end-to-end frontend engineering for Sapphire Broking's trading platform.
Responsibilities in this role:
- Setting the frontend architecture — component structure, state management patterns, and API integration conventions the team would follow
- Building and shipping production trading dashboards using Next.js and TypeScript
- Implementing pixel-accurate UI from Figma designs while making pragmatic engineering tradeoffs
- Mentoring junior developers, reviewing their PRs, and helping them develop sound TypeScript and React practices
- Coordinating closely with backend and product to define API contracts and data shapes
The frontend engineering challenges in financial applications are different from typical product UIs. Market data changes rapidly, the information density is high, and performance matters — a sluggish dashboard is not just a UX problem, it's a business problem.
Frontend engineering focus:
- Reusable, composable React component library
- Real-time data rendering from WebSocket streams
- Responsive dashboard layouts with high information density
- TypeScript-strict codebase with well-defined API types
- Optimized rendering to handle frequent state updates from live market feeds
- SEO-engineered public-facing pages that ranked highly on Google for relevant industry searches
Owning the frontend end-to-end taught me what it means to be responsible for a surface — not just implementing features, but maintaining standards, growing the team, and making architectural calls.
Phase 2: Backend Migration with Go
After establishing myself on the frontend, I moved to the backend team — a deliberate decision to deepen my understanding of how the system actually worked beneath the UI.
This is where I picked up Go for production backend engineering.
Backend responsibilities:
- Building and optimizing REST APIs consumed by the frontend trading dashboards
- Integrating with NSE and BSE exchange systems — handling their API contracts, request formats, time-sensitive data, and failure modes
- Writing performant backend services where response latency and throughput directly impacted trading workflows
- Collaborating with the existing backend team to maintain consistency across services
Why Go for financial systems:
Go's concurrency model, compiled performance, and explicit error handling make it a strong fit for financial backends where predictability matters. A runtime panic in a trading service is not acceptable — Go's design encourages you to handle every failure path explicitly.
Exchange Integrations
Working with NSE and BSE systems introduced a class of engineering problems different from standard internal APIs:
- External systems have their own rate limits, retry semantics, and API versioning cycles
- Time-sensitive data must be handled carefully — stale prices have real consequences
- Error conditions are more nuanced: a failed request might mean "retry," "pause," or "alert immediately"
- Data normalization becomes important when the external system's format doesn't match your application's domain model
Learning to build reliable abstractions over external financial systems was one of the most valuable engineering lessons from this engagement.
What This Arc Taught Me
Starting on the frontend and deliberately moving to the backend gave me something most developers take years to develop: genuine empathy for both sides of the stack.
When I'm working on a backend API, I understand the frontend contract it needs to satisfy. When I'm on the frontend, I understand the backend constraints that shape what's possible.
That full-stack fluency — earned through real production engineering on both sides — is one of the things that makes me a more effective engineer and collaborator on complex projects.