Back
KR

2025.10 – Now

SunLabs AG· OrderXFE Part Lead

A terminal that starts from crypto and is heading toward an institutional . It handles crypto venues (Deribit, Hyperliquid, Lighter, Bybit, Binance) and traditional markets (OPRA US options, CME, IBKR) on one screen. Piloted with a large ; $10B processed and $1M in revenue during private beta. I built the frontend from initial setup as the sole owner, pairing on the harder stretches, and designed its 18 feature domains.

Impact

Projects

Order execution and multi-exchange support

2025.12 – 2026.09

Problem · Traders hold several accounts across venues like Deribit, Hyperliquid, and Bybit, and the same BTC option has a different symbol, decimals, and margin model on each. They used to hop between exchange screens to trade, and a slip sent money to the wrong account or instrument.

  • One that selects several instruments and submits them together as a . Each leg gets an so the preview shows an expected fill, and nothing leaves without passing validation.
  • An rule that combines instrument, venue, and the user's choice to pick the destination account automatically, blocking wrong-account mistakes in the UI.
  • Venue symbol formats (Deribit 'BTC-26DEC25-90000-C' vs OPRA 'IBIT_271217P00048000') handled as structured fields (underlying, expiry, strike, call/put) rather than strings, so adding a venue does not break order logic.
  • Professional order types layered on top: brackets, quotes, matrix orders, , simulation, slicing, .
  • Found that the passed to the AI for chat orders could not express batch orders or TP/SL, wrote the fix as an , and changed the protocol with the backend team. Proposed '@account' tags to route each instrument to its own account.
  • Showed that merging positions from several accounts into one table is unsafe because server messages carry no account identifier, and documented it as a backend change request.

Browser memory optimization (3.8GB → 1GB)

2026.04 – 2026.08

Problem · Real-time streams, widget state, TradingView iframes, and query caches accumulated until Chrome sat at 3.8GB, slowing the UI and eventually killing the tab.

  • Split orderbook and position table updates down to row and symbol granularity to remove redundant re-renders and allocations.
  • Replaced AG Grid with an in-house DataTable with row memoization, virtualization, and clean unsubscribe paths.
  • Three-stage runtime recovery: partial resubscribe, then cache invalidation, then reload when returning from a background tab. Reloads are blocked while an order is being entered.

Translate-based in-house grid system

2026.06 – 2026.09

Problem · react-grid-layout recalculated layout and re-rendered React on every mousemove during resize, saturating the CPU.

  • dnd-kit plus imperative DOM transform (translate) updates so React is out of the loop while dragging.
  • Grid-to-pixel math isolated in pure functions and pinned with tests.
  • Widget stretch and shareable page layouts with auto-generated OG images.

AI workflow adoption

2026.01 – 2026.09

Problem · A small team had to push MVP features across 18 domains at once. Single-model, single-agent work shipped fine on day one but left edge cases behind, so the same feature had to be reopened days or weeks later.

  • Repository conventions, architecture, and domain rules fixed through context injection so any agent works to the same standard.
  • Claude as planner, Codex as reviewer (planner / reviewer): design, implementation, and review separated, with plan/design documents and gap analysis as the audit trail.
  • react-doctor cleanups run as a routine so debt from feature integration does not accumulate.
  • Outcome: coverage over speed. Edge cases caught at review removed one to three-plus working days of rework per feature.

Figma MCP + i18n agent pipeline

2026.06 – 2026.09

Problem · Design changes and translated copy were applied by hand, so every release shipped with omissions and mismatches.

  • Figma MCP reads the design source directly to apply component changes.
  • An i18n agent finds missing keys, translates and registers them, and syncs with Lokalise. Localization runs on next-intl.

Chart library migration (lightweight-charts → TradingView)

2026.03 – 2026.09

Problem · The backend speaks Protobuf over HTTP plus WebSocket rather than a standard feed, so TradingView's stock Datafeed did not fit.

  • Provider-pattern custom Datafeed. Position and execution overlays, live quote push, per-account overlays.
  • Custom indicators (OI profile, visible-range profile, cross-exchange studies) and a range-preset toolbar. Analytics widgets such as FedWatch, an economic calendar, and SVI parameters.

Stack

Frontend
Next.js 15, React 19, TypeScript, Bun, Tailwind v4, Radix UI, Jotai, TanStack Query, React Hook Form, Zod, dnd-kit, framer-motion, react-virtuoso
Realtime
Protocol Buffers (ts-proto) over HTTP + WebSocket
Chart
TradingView Charting Library v31, TitanCharts, ECharts
AI
Vercel AI SDK, assistant-ui, ElevenLabs
Tooling
Playwright, Bun test, Lokalise, PostHog, OpenTelemetry, AWS Amplify