The things I spend most of my time thinking about. Some published, some private, some still being built. Rough order is what I'd bring up first in conversation, not date.

Table of Contents

Automated trading platform

Solo project I've been building since May 2025. I wanted to see if I could write something solid enough to put my own savings into. Around 200 Python modules with asyncio at the core.

The hardest engineering problem has been making the same strategy code run identically against a mock, a broker's paper account, and a real account. I settled on a single exchange-abstraction protocol that Interactive Brokers, IG, OANDA, and Alpha Vantage all implement — flip one flag and the same strategy runs anywhere. A few of the other problems I've had to solve along the way:

  • Keeping positions in sync when the broker's record of the world diverges from mine. Three-step reconciler: retry with backoff → query the original order's fill state → issue a corrective adjustment. Catches the case where a fill happens but my local record missed it.
  • Not eating overnight swap fees. A timezone-aware guard that auto-closes positions before the broker's daily swap cutoff. Getting the timezone right matters more than it sounds — the UK and US change clocks on different weekends, so the gap between UK time and market time shifts for a few days each spring and autumn.
  • Backing off under broker-API pressure without dropping signals. Adaptive rate limiting that responds to the observed error surface rather than a fixed ceiling.
  • Exercising hypotheses safely. A shadow / paper-trade mode that runs the full stack against a real market feed but routes orders to a mocked venue — the code path is identical to production, only the execution boundary differs.
  • Finding performance regressions after the fact. memray-profiled runs with per-strategy balance tracking, so I can localise where throughput dropped between strategy generations.

A separate FastAPI monitor sub-app runs alongside the core — live PnL / Sharpe / drawdown views, live trade snapshots, WebSocket updates for near-realtime refresh, and Pushover alerts if anything goes critical. Hosted on my own cloud, not linked publicly. A demo login opens the live dashboard with a few fields masked — request access →. An ML-gated signal filter (so a trained classifier can veto signals before they become orders) is under active development.

python-clean-architecture

Claude Code plugin I built that applies Python clean-architecture practices to your code while you work — rather than leaving them in a textbook you half-remember. Published on the Claude Code marketplace and on Codex CLI; install with /plugin marketplace add MKToronto/python-clean-architecture.

The motivation: I'd worked through Arjan Codes' courses on the designer mindset, Pythonic patterns, and FastAPI clean architecture, and the principles were excellent — but I kept finding myself breaking them on real code, especially under deadline. The plugin is the missing feedback loop.

Twelve slash commands covering the full lifecycle of a Python service — scaffold-api, add-endpoint, scaffold-tests, refactor-legacy, extract-god-class, decouple, make-pythonic, review-architecture, review-api-design, check-quality, diagnose-smells, and suggest-patterns. Each returns findings by severity with file:line references and fix snippets.

Skill pack underneath — more than fifty reference files: seven design principles paired with refactoring recipes, twenty-two code-quality rules, twenty-five Pythonic patterns. A working FastAPI hotel-booking example demonstrates the full architecture with tests.

Architected and directed by me; Claude wrote most of the prose under iterative direction, with me curating skill boundaries and validating every reference against source material. Arjan's courses are attributed explicitly in the README.

localytics

While building the trading platform I wanted the kind of activity dashboard GitHub Insights gives you — commit rhythm, function-level complexity, churn heatmaps — but without pushing private source onto a hosted platform that might quietly vacuum it into training data.

So I built localytics. A local FastAPI server runs on your machine and analyses a codebase in place: commit activity, function-level cyclomatic complexity (via Radon), file-type mix, per-file churn, weekly / monthly / yearly activity heatmaps. A small Render-hosted FastAPI dashboard (backed by Redis) displays the results. Only aggregated numbers cross the wire — the source itself never leaves your machine. The link between the two is TLS-encrypted so the API-key headers can't be sniffed off the network. Dependencies are self-contained via PEP 723, so uv is the only thing you need on the host. MIT-licensed. Live demo →

docugit

Companies can claim R&D tax credits for engineering work, but writing up the report is tedious — you have to trawl months of commits and paraphrase what was built, per-project, per-period. docugit does the boring part.

A CLI that pulls detailed git code-changes from one or more repos over a configurable time range (weekly, bi-weekly, monthly, quarterly, yearly), with per-file-type and per-folder include/ignore filters so it focuses on real engineering work and skips generated files, dependency directories, and docs. The output is shaped for LLM ingestion — feed it to ChatGPT or similar and it produces a draft report you can edit rather than write from scratch.

quant-finance

Private plugin I use inside the trading research. Seventeen skills plus a dedicated quant-expert subagent, operationalising Marcos López de Prado's three books on quantitative machine learning — triple-barrier labelling, fractional differentiation (with ADF stationarity testing and weight-formula derivation), covariance denoising (Marcenko-Pastur bounds), causal-factor validation (confounder / collider / mediation Monte Carlo experiments), sample weighting, microstructural features (Kyle / Amihud / Hasbrouck lambdas, PIN / VPIN), and a seven-sins backtest validator (combinatorial purged cross-validation, embargo, deflated Sharpe, probability of backtest overfitting). Lets me invoke the methodology by name as I work.

Private — contact me for more information.

anaconda_set_up

Small bash utility for bootstrapping Anaconda on macOS in one command. Detects an existing install and skips if present; otherwise downloads and installs Anaconda without needing the binary pre-shipped alongside the script; then sets up a named environment from a YAML file. Handles the macOS permissions up-front so the user doesn't have to visit Security settings to "open anyway".

Fortress Technology (2019–2024)

Over five years at Fortress I built the real-time Python image-processing layer, the operator UI, and the data-ingestion and labelling tool that together made up the flagship ICON X-ray inspection machine — plus a first-project customer ship (a pill-dispensing control app for an external client) and the tool that keeps the machine's UI translated across 40+ languages. The ICON runs on Raspberry Pi edge hardware and is deployed across many hundreds of production facilities worldwide. Zero post-ship bugs and no customer complaints across every piece of code that shipped. The through-line across all of it: making Python perform in an embedded context, and owning the product surface end-to-end — from what the operator sees on-screen back to the data pipeline that trained the model behind it. Product demo → · Fortress ICON product page →

Real-time image-processing stack

The problem: take the raw 16-bit output off the X-ray detector, find contaminants (bone, metal, ceramic, glass), and draw them on a live image the operator sees — in real time, on a Raspberry Pi, in Python, while living alongside a pre-existing C / OpenGL / Perl stack that already ran the machine.

The C detector code was already on the machine and wasn't mine to write. My job was building the Python side: the algorithms, the performance engineering, the interop with the C layer, and the async web server that ties it all together.

Interop. The C side wrote image data and detection flags into a SysV shared-memory region. Python reads it via sysv_ipc, with byte offsets computed programmatically from a numpy dtype that mirrors the C struct — rather than hardcoding offsets that would drift the next time someone edited the C header. A small parser ingests the C header's #define constants and caches them to JSON so both sides stay in sync without anyone having to remember.

Performance. Getting Python fast enough for real-time meant numba-JIT compilation on the hot paths — @jit(nopython=True, parallel=True, fastmath=True) with prange for the parallel loops. Numba has holes you only discover by hitting them: it doesn't support np.unravel_index in nopython mode, so pixel coordinates are unravelled explicitly (idx // width, idx % width) inside the JIT loop. Under performance pressure the rendering geometry degrades adaptively — brush radius scales by sqrt(skip_factor) — so the machine gracefully lowers visual fidelity rather than falling behind. Recursive hole-filling for the contaminant overlay has configurable stop thresholds so it doesn't pathologically descend on degenerate inputs.

Atomic publishing. Output images are published via hardlink_to → .replace() — the canonical Unix pattern for hot-file swaps — so the UI never reads a half-written image, even when the writer is mid-flight.

Async web server. FastAPI + WebSocket serves the UI and the operator-facing API. Nine distinct asyncio.Lock()s partition the shared state by region — recent/past image state, binary data, batches, metadata, memory view, and so on — each narrow enough that they rarely contend in steady-state operation. The shared-memory polling is blocking I/O, so it runs in a ThreadPoolExecutor and feeds the async server through an asyncio queue.

Empirical bottleneck finding. Per-run metrics write to a CSV and a small analysis script runs Pearson correlation against the configuration knobs to identify which ones actually move throughput. Beats guessing.

Offline dev tool. Separately, I wrote a large Python layer that safely binds six compiled C extensions via ctypes.CDLL for offline batch conversion of raw detector binaries into PGM/RGB — pre-allocated buffers with explicit sizes, no overrun surface. Used to build training data and diagnose field issues. Not in the real-time path.

Camera monitor screen

The ICON has two operator screens — the main X-ray graphics UI (part of the image-processing stack above) and a second screen that gives operators a live multi-camera view of the machine and the product line around it. This project is the second one.

A SvelteKit application (Svelte 3 + Vite + TypeScript + static adapter) served inside kiosk-mode Chromium on Raspberry Pi. Live camera feeds, thumbnail strips, selection workflow. Full embedded deploy pipeline too — mamba environments, screen sessions for process supervision, boot-time startup, offline-packaged install so a field technician can deploy without internet access.

Owned end-to-end — Svelte UI, Python orchestration, the deploy pipeline — through seven iterations of streaming approaches (WebRTC, aiortc, HLS, gstreamer) before I landed on the kiosk design that shipped. The winning design was the simplest one, and that's almost never the first one.

Data-ingestion and labelling tool

The problem: the ML models downstream needed training data, and there was none of the right shape. I made the strategic case to R&D leadership that Fortress needed to invest in labelled-data acquisition, then built the tool that executed the strategy.

An internal web app that pulled time-windowed image batches from 100+ fielded X-ray machines over SSH — paramiko with TCP keep-alive so long batch pulls didn't hang up mid-download, recursive SCP pull, remote auto-save toggling — queued batch conversion through the C pipeline via Redis / RQ workers, and presented the results in a Svelte SPA (Svelte 3 + Bootstrap + socket.io + Tailwind + TypeScript) where operators manually categorise contaminants and log per-image metadata. This tool built the dataset every downstream anomaly-detection model depended on, and the labelled contaminant data it gathered went on to influence the hardware design of the next generation of machines.

Deployable field image

The Docker toolchain that packages the production image-processing build plus the UI environment into a deployable image for field machines. VLAN setup, startup scripts, bundled toolchains, mounted-volume layout. The variant that actually shipped to field hardware.

Pill-dispensing control (first Fortress project)

Founding engineer end-to-end on a customer-facing product Fortress shipped to an external client. Flask control application talking to the physical dispensing hardware, with user-editable calibration for precise dispensing, delivered as versioned releases. Shipped with zero post-ship bugs and no complaints from the customer — on a first project. Messy repo, clean ship: the production record is the real signal.

Multilingual HMI pipeline

The problem: the machine's touchscreen UI has to stay translated across 40+ languages as the product evolves, and the people doing the translation aren't engineers — they live in Excel. Any tool that depended on them editing structured JSON directly would have failed on contact with reality.

The solution: a bidirectional JSON ↔ Excel pipeline. The source-of-truth JSON gets exported to a locked Excel file — uneditable columns where editing would break structure, bold highlighting on untranslated entries so nothing slips through. Translators work in Excel as normal; edits merge back into JSON safely. Language auto-detection, source-language management, and wordhoard thesaurus integration (with rate-limit retry and caching) so translators aren't starting every label from a blank field. Packaged with an Anaconda installer and a single launch script so non-technical staff could run it without any engineering help.