[00]Projects
Systems that had to stay up.
Contract work, start to finish. Each one has the part that was actually hard, because that is the only part worth reading.
Ostium
Contract senior engineer · 2026 — ongoingA hedging engine holding market exposure for a $38B exchange.
- volume
- $38B+volume
- end to end
- <50msend to end
- broker integrations
- 6+broker integrations
- assets and tick rate
- 10×assets and tick rate
Context
Perpetual futures exchange backed by General Catalyst and Jump Crypto. I architected the Golang hedging engine from zero to one — the system that manages the exchange’s market exposure.
The part that was hard
Always-on inside a 50ms ceiling means there is no manual intervention path — it degrades correctly on its own or it loses money. Then the same system had to carry ten times the assets at ten times the tick rate, without widening the budget.
What I built
- Hedging engine from 0 to 1, running 24/7 with end-to-end execution under 50ms
- Scaled the pricing system from a 100-asset cap to 1000+, and tick rate from 1/second to 10+/second — 10× on both axes
- High-throughput ingestion for real-time order flow and pricing
- Modular, fault-tolerant architecture so core logic could iterate while market-maker integrations scaled in parallel
- Async data pipelines feeding high-fidelity market data to risk for backtesting
- Automated reconciliation and circuit breakers for extreme volatility
- Go
- AWS
- Postgres
- WebSockets
QA agent pipeline
Contract · Jan — Mar 2026PRDs in, reviewed test plans out. 60% of the cases run without a human.
- fewer production bugs
- 40%fewer production bugs
- fewer regression bugs
- 30%fewer regression bugs
- cases run without a human
- 60%cases run without a human
- LLM calls in CI
- zeroLLM calls in CI
Context
A games studio where QA read every PRD by hand and wrote test cases from it. Slow enough that a full regression pass only happened near release — which is exactly when finding a bug is most expensive.
The part that was hard
The classification. Every case is labelled automated, AI-manual or human before anything runs, and being wrong in either direction kills the tool — over-automate and QA stops trusting the results, under-automate and you have built an expensive way to write documents. Draw that line honestly and the rest follows: tests cheap enough to run constantly, and QA spending their hours on the cases that needed a person.
What I built
- Knowledge base ingest over Confluence — photos, renders, past PRDs and supporting docs — so generated cases matched how the product actually behaves
- Incremental PRDs: each revision generated against what changed, not the whole spec every time
- Every case emitted with a title, steps, acceptance criteria and a run type — automated, AI-manual or human
- A parallel path pulling the relevant regression cases out of the existing corpus rather than regenerating them
- Both paths assembled into a test plan a human reviews and edits — add, remove, update — before anything runs
- Three execution lanes in parallel: automated tests generated and run, AI-manual runs executed and documented, human cases routed to people
- Approved automated tests promoted into CI, where they run with no model in the loop
- Cost controls throughout — per-stage model selection through OpenRouter, prompt caching over the stable knowledge-base context, runs traced in LangSmith
- Python
- LangGraph
- LangSmith
- OpenRouter
- AWS
- pytest
Rage Trade
Contract tech lead · 2021 — 2025$6B+ routed across 8+ exchanges, on AWS ECS.
- volume routed
- $6B+volume routed
- exchanges
- 8+exchanges
- latency cut
- 50%latency cut
- TVL in vaults
- $15M+TVL in vaults
Context
Perpetual futures aggregator routing across 8+ exchanges on EVM and SVM chains, investors including OKX and Zee Prime Cap. I owned full-stack architecture and delivery, joining as a smart contract engineer and leaving as tech lead.
The part that was hard
Eight venues that disagree about everything — settlement, precision, failure semantics — surfaced to users as one interface. Integration velocity was the bottleneck, so I built reusable tooling and automated tests around it and roughly halved the time to add a venue.
What I built
- NodeJS microservices platform on AWS ECS with zero-downtime CI/CD
- Data layer moved to event-driven WebSockets — trade latency cut 50%
- Modular SDK decoupling UI from exchange logic, enabling parallel work
- Seeded USDC liquidity mechanism for Hyperliquid’s HIP-2, part of the core protocol
- Technical execution of a token sale that raised $6M in under 30 minutes
- ERC-4626 vaults integrating GMX, Aevo and Uniswap — $15M+ TVL
- TypeScript
- Node
- AWS ECS
- Solidity
- Postgres
octomux
Built and maintained · 2026 — presentMulti-agent orchestration, in the open.
- lines TypeScript
- 158klines TypeScript
- commits
- 1,655commits
- test files
- 399test files
- agent harnesses
- 2agent harnesses
Context
A platform for running autonomous coding agents on real repositories: an isolated git worktree and tmux session per task, pluggable harnesses, automated PR review gating merges, and scheduled crews that run unattended.
The part that was hard
Agents that write code are only useful if you can trust the diff. Most of the work is not the agent — it is isolation, review gates, spend caps and recovery. The same discipline as trading infrastructure: evals are risk controls, guardrails are limit monitoring, spend caps are position limits.
What I built
- Task orchestration with one isolated workspace per run, so parallel agents cannot collide
- Pluggable harness layer — Claude Code and Cursor, swappable
- Multi-lens automated PR review before anything merges
- Scheduled agent crews, cron-driven, unattended
- Per-task model routing and crash-resume for in-flight work
- TypeScript
- Node
- SQLite
- tmux
- git
Have something like this to build?
Scope and cost get decided on the call, against your actual problem. Thirty minutes is usually enough to tell whether it is worth either of our time.