Sujal
Sharma.

A C++20 trading system I built solo with heavy AI assistance, to learn low-latency engineering from the ground up. Order book, pre-trade risk gate, strategy engine and a replayable WAL over Aeron IPC and an SBE wire format, with a QuestDB tick store and a Next.js 16 control plane. ~11,100 lines of hand-written C++ plus a 24,300-line dashboard, 173 tests. The repo also documents a latency table I withdrew: the harness was timing a single operation between two steady_clock reads, and on Apple silicon that clock's 41.7ns tick meant every published figure was one or two ticks of the instrument rather than a measurement of the code.

• → live demo
• → race the engine
• source available on request

End-to-end algorithmic trading platform. Python backend pushes signals from a strategy engine through Redis pub/sub to an order manager that executes against Angel One (paper or live). Next.js 15 frontend on Prisma/Postgres for users, strategies, orders, and portfolio tracking. Two repos, one system.

• → backend repo
• → frontend repo

A native macOS app that talks directly to the Kubernetes API. Decodes Opaque secrets in-place, edits with bulk .env import, scales deployments, streams pod logs with severity filters, and handles port-forwarding with retry. Multi-cluster, multi-window, keyboard-driven. MIT.

• → product page
• → source on github

The sync failure that matters is not the one that pages you, it is the one where the job completes, logs a row count and is quietly wrong. Checking properly means comparing every row on both sides every time, so nobody runs it. driftscan buckets the key space and compares a row count plus an order-independent XOR of row hashes per bucket — one grouped query per side whatever the table size — then opens only the buckets that disagree: finding six bad rows in fifty thousand reads 1,195 of them. It normalises decimal scale, timestamp precision and bool/int before hashing, because a detector that reports every type round-trip as drift stops being read after the third false alarm; each normalisation is lossy on purpose, so each is named in the report. And it has three verdicts rather than two, because “I found nothing” and “I stopped looking” call for opposite responses.

• → github on github

Most eval tooling reports that prompt A scored 73% and prompt B scored 76%, and leaves you to draw the obvious conclusion. On sixty cases at a non-zero temperature that conclusion is usually wrong. evalgate repeats every case, pairs the comparison so case difficulty cancels, and separates “no difference” from “not measured” — withholding a winner when the bootstrap interval spans zero and saying how many cases would have been needed. Detecting a +3-point improvement on a 73% baseline takes roughly 3,300 cases per variant; most published comparisons use 50–100.

• → github on github

Backup tooling reports the claim as the fact: the dump exited zero, the file is on disk, the dashboard is green. None of that establishes the data can come back. This runs Postgres with streaming replication and WAL archiving, then continuously tries to disprove its own backups by restoring each one into a throwaway instance and querying it. Three states and no fourth — VERIFIED, UNVERIFIED, FAILED — and the backup script writes UNVERIFIED on success, because exiting zero is not evidence. It caught its own failure mode while being built: a permissions mistake meant the restored container ran initdb and came up as a pristine empty cluster, perfectly healthy and completely empty. Only the query step noticed.

• → github on github