01
WEAVE-DB
Version control for a live PostgreSQL database. Write operations are versioned through inverse-query generation, so a data or schema change can be undone the way a commit can, rather than recovered from a backup taken hours earlier. Replaying inverse queries forward from the base gets expensive the further along the history you go, so the engine anchors on the nearest snapshot on either side of the target and replays towards it, halving the worst case from K−1 steps to ⌊K/2⌋. A Kafka layer added afterwards keeps replay deterministic under concurrent multi-user access, with each user's database credentials held encrypted. Built by four of us, with me leading the backend.
Django · FastAPI · PostgreSQL · Kafka · AWS S3 · React · TypeScript
02
SimRUN
A system design tester. You draw an architecture, services, caches, databases, load balancers, circuit breakers, and SimRUN runs it under configurable load with failure modes injected, so you find out how the design degrades before building any of it. Underneath is a discrete-event scheduler in C++ dispatching events in strict timestamp order across concurrent services, with components modelled through an orthogonal 20-opcode set that covers cancellation, scatter-gather fan-out and preemptive eviction. Chaos runs forecast P50 and P99 latency against SLO thresholds. Designs are written in a small DSL I built the front end for, lexer through semantic validation, so a malformed service graph is rejected before the run starts rather than halfway through it.
C++ · STL · Discrete-event simulation · Lexing & parsing
03
ONITRO
ONITRO is a C++20 quantitative finance library I architect and lead-mentor a team of engineers on, built to close the performance-vs-usability gap between QuantLib (comprehensive but dated) and scattered Python tooling. It computes options pricing (Black-Scholes-Merton), Greeks, implied volatility, Monte Carlo simulation, and portfolio risk metrics (VaR, Expected Shortfall) — a calculator, not a forecaster. The design centers on a few hard architectural constraints held from day one: struct-of-arrays layout, branch-free and allocation-free hot paths, NaN sentinels instead of exceptions for error handling, and hand-written AVX2 intrinsics rather than relying on auto-vectorization (which silently fails on transcendental math and divergent branching). Each module follows a strict scalar-kernel → SIMD-kernel → chain-driver anatomy, and the whole library is exposed to Python via nanobind with zero-copy NumPy interop.
C++20 · AVX2 · nanobind · NumPy interop · Numerical methods
04
Custom Language & Interpreter
A language with its own syntax and its own datatypes, built as a team. My part was the front half: lexing the source into a typed token stream, then parsing it into an AST against the grammar rules that define the language's precedence and associativity. From there we wrote an interpreter that walks that tree and executes each node as C code, so a program's behaviour comes out of the tree's shape rather than any intermediate representation. Building both halves is what stops precedence and associativity being rules you memorise, since they stop being rules at all and turn into consequences of productions you wrote yourself. Custom datatypes were the part that forced the most rethinking, because the tree walker has to carry type information through evaluation rather than assuming everything is a number.
C · Flex · Bison · AST & tree-walking interpreter
05
Maze Pathfinding Visualiser
Five search algorithms raced across randomly generated mazes and rendered step by step, so the difference in how they explore is visible rather than described. BFS, DFS, Dijkstra, A* and greedy best-first each subclass one solver base, which is what keeps the comparison honest: same maze, same interface, only the search order differs. A benchmark screen puts runtime, nodes explored and final path length side by side, and the number worth looking at is how many fewer cells A* has to touch to return the same shortest path BFS does.
C++17 · SFML · Algorithms · OOP
06
The Hive
A browser extension that tracks which tab you're on and classifies it by vector search into categories, turning that into a productivity score. Users are then rated against that score, which nudges time towards productive work rather than just reporting on it. The interesting constraint was making the score unfarmable: a minimum-time threshold and an idle check mean nobody can inflate their numbers by leaving a tab open and walking away. Activity is categorised by 384-dimensional embeddings searched through PostgreSQL pgvector HNSW indexes, syncing over WebSockets into a Node and Express backend.
Node.js · Express · PostgreSQL · pgvector · Kotlin · WebSockets