COMPUTER SCIENCE · SOFTWARE ENGINEERING / LONDON

I build software for quantitative research, portfolio tracking, and data-heavy problems.

I’m a computer science student focused on backend and platform engineering. I also work on embedded systems and machine-learning experiments.

MEASURED QUERY
347 ms → 1.05 ms
From complexity to clarityA stepped system diagram moves from complex input through structure, model, and signal to a useful decision.INPUT / 01STRUCTUREMODELSIGNALDECISIONFIG. 001 — SYSTEM TRANSFORMATIONX / COMPLEXITYY / CLARITYFrom complexity to clarityA stepped system diagram moves from complex input through structure, model, and signal to a useful decision.FIG. 001 — SYSTEM TRANSFORMATIONINPUTSTRUCTUREMODELDECISION
COMPLEX INPUTSTRUCTURED PROCESSUSEFUL OUTPUT
SCROLL TO INDEX

Four projects: a portfolio app, a quantitative research tool, a poker engine, and a neural pitch shifter.

01 / THE PORTFOLIO APP · 2026—PRESENT · ACTIVE · FUNCTIONAL STAGING

A portfolio tracker built across four backend services.

A working portfolio tracker for virtual accounts and shared households. It records transactions, calculates holdings, valuation, P&L and time-weighted returns, and tracks allocation drift using live prices.

STATUS / DATE
Functional staging
August 2026
ROLE
Creator
SERVICES
4 deployed backend services
CONTRACTS
REST · gRPC · codegen
PLATFORM
k3s · Helm · Terraform
The Portfolio App dashboard showing portfolio value, return, benchmark comparison, performance chart, and a table of nine positions.
PLATE 01 / THE PORTFOLIO APPPUBLIC STAGING DEPLOYMENTLIVE PRODUCT · AUGUST 2026
Technical details
  1. 01 / BOUNDARIES

    FastAPI handles the main product workflows. Rust handles quote ingestion and calculation-heavy work. The public API uses OpenAPI; services communicate over gRPC using protobuf.

  2. 02 / CORRECTNESS

    Transactions are the source of truth. Positions and daily NAV can be rebuilt from the ledger, and a dirty watermark queues recalculation when an older transaction changes.

  3. 03 / SECURITY

    The gateway signs tokens with Ed25519. Other services validate them from the public JWKS and receive audience-scoped credentials that expire after 60 seconds.

  4. 04 / DELIVERY

    Terraform provisions Hetzner and Cloudflare. Helm deploys the services to k3s after database migrations, and Playwright checks the deployed commit before it is marked ready on staging.

The Portfolio App staging architectureA SvelteKit web application reaches FastAPI services over public REST; portfolio, pricing, and calculation services communicate through generated gRPC contracts and store state in Neon Postgres, Upstash Redis, TimescaleDB, and Cloudflare R2 on a Terraform-provisioned k3s platform.STAGING / CONTRACT-DRIVEN SERVICE GRAPHSVELTEKITWEB / BFFAPI GATEWAYFASTAPI / RESTPORTFOLIOFASTAPI / LEDGERPRICINGRUST / TonicCALCRUST / PolarsHTTPSRESTgRPCgRPCNEONPOSTGRESUPSTASHREDISTIMESCALEDBPRICE HISTORYR2BACKUPSTERRAFORM → HETZNER → k3s → HELMCLOUDFLARE EDGE / DOPPLER SECRETS
Performance & reliability4 examples from the current build
  1. 01 / QUERY PATH347 ms → 1.05 ms

    TimescaleDB continuous aggregates reduced a measured six-symbol, 1.55-million-row price-history query while returning all 546 chart points identically.

  2. 02 / IDLE COST≈3.1M → 0 writes/month

    Quote caching changed from supply-pushed polling to demand-filled write-back, eliminating projected Redis writes when staging has no active readers.

  3. 03 / FAN-OUT2H → ≈2 Redis commands

    A sparse GetQuotes gRPC batch resolves up to 256 symbols through one MGET and one set-based Timescale query instead of one quote call per holding.

  4. 04 / AUTH STATE6 → 1 mint commands

    An atomic Lua script replaced six refresh-token mint operations; complete issue and rotation flows fell from 8/9 commands to 3/4.

FUTURE / DOCUMENTED ROADMAP

From tracking value to explaining risk and tax.

  1. 01
    Statistics and risk

    I’m adding rolling volatility, drawdown, Sharpe and Sortino ratios, benchmark beta, historical VaR, correlations, Monte Carlo projections, and factor exposure. Each calculation will be checked against reference fixtures before it appears in the Risk interface.

  2. 02
    UK capital gains

    A Rust tax service will implement HMRC same-day matching, the 30-day bed-and-breakfast rule, and Section 104 pooling, with worked-example and property tests plus tax-year reports exported to R2.

  3. 03
    Production connections

    The next step after staging is direct Trading 212 and IBKR sync, production OAuth, and clearer failure states.

  4. 03 / VIEW FINAL ROADMAP ITEM
    Production connections

    The next step after staging is direct Trading 212 and IBKR sync, production OAuth, and clearer failure states.

02 / OPENQUANT · 2025—2026 · ACTIVE · PRE-RELEASE ALPHA

Run and compare reproducible backtests from Python strategies.

An early alpha for running Python strategies and inspecting the results. Each run records its code, parameters, data version, engine version, and random seed. The current build has completed a 190-trial grid search.

STATUS / DATE
Pre-release alpha
August 2026
ROLE
Creator · Full-stack engineer
RESULT
190 / 190 sweep trials completed
DATA
4 sources
PORTFOLIO
Up to 50 symbols
SWEEPS
190 verified · 10k limit
OpenQuant light-theme market research workspace showing an AAPL candlestick chart, volume, data controls, and symbol panel.
PLATE 02 / OPENQUANTMARKET RESEARCH WORKSPACEREAL PRODUCT CAPTURE · AUGUST 2026
Technical details
  1. 01 / DATA

    Research can use Yahoo Finance, Binance, Twelve Data or local CSV files, with portfolios of up to 50 symbols.

  2. 02 / RUNS

    Grid and seeded-random searches support up to 10,000 trials. The run shown completed 190. Strategy code runs without network access and under process resource limits.

OpenQuant research architecturePython indicators and market data flow through parameter sweeps and reproducible backtests into portfolio results.PYTHON INDICATOR / MARKET SERIESREPRODUCIBLE RUNRESEARCH EVENTPYTHON SCRIPTPARAMETER SWEEPBACKTESTPORTFOLIO

03 / POKER TUI · 2025 · COMPLETE · MAINTAINED

A Texas Hold’em engine and terminal interface written in Rust.

A Rust terminal game built around a pure poker engine, local bots, live equity estimates, and a networked client/server mode.

STATUS / DATE
Complete · Maintained
2025
ROLE
Creator · Rust engineer
RESULT
Includes the game engine, terminal UI, bots, equity estimates and client/server play. The image below is an illustration, not a product screenshot.
SYSTEM
Game engine · TUI
FOCUS
State · Probability
STACK
Rust · Ratatui
Poker TUI technical illustrationAn illustrative Texas Hold'em table state with four seats, five community cards, action options, and an equity rail.HAND STATE / 17A♠10♦7♣K♥POT / 1,24001BOT / 0202BOT / 0303YOU / 0104BOT / 04EQUITYILLUSTRATIVE STATEFOLDCALLRAISE →CORENETSERVERCLIENT
PLATE 03 / POKER TUIRULES, STATE, AND PROBABILITYILLUSTRATIVE HAND STATE
Technical details
  1. 01 / CORE

    A pure poker engine keeps game rules separate from the terminal interface.

  2. 02 / STATE

    Bots choose from the legal actions for the current hand, while the interface updates the equity estimate as cards are dealt.

04 / NEURAL PITCH SHIFTER · 2026 · ACTIVE EXPERIMENT · TRAINING

An experiment in shifting pitch without losing timbre.

The pipeline uses a conditional U-Net to predict a pitch-shifted mel-spectrogram, then HiFi-GAN turns it back into audio. Demucs can separate vocals before processing.

STATUS / DATE
Experimental · No validated result yet
August 2026
ROLE
Creator · ML engineer
RESULT
The pipeline is implemented, but training and model comparisons are still in progress. The diagram shows the intended signal flow.
SYSTEM
Audio pipeline
FOCUS
Pitch · Timbre
STACK
PyTorch · DSP
Neural Pitch Shifter technical illustrationAn audio waveform and mel-spectrogram pipeline showing conditional pitch transformation and resynthesis.AUDIO / CONDITIONAL TRANSFORMATIONINPUT WAVEFORM22.05 KHZTARGET MEL-SPECTROGRAMF0 + SHIFTPITCH U-NETHI-FI GANAUDIO
PLATE 04 / NEURAL PITCH SHIFTERCONDITIONAL AUDIO TRANSFORMATIONILLUSTRATIVE SIGNAL PIPELINE
Technical details
  1. 01 / MODEL

    A pitch-conditioned U-Net predicts the target mel-spectrogram.

  2. 02 / OUTPUT

    HiFi-GAN resynthesizes audio; Demucs can isolate and remix vocals.

Pitch U-Net model architectureFour residual encoder blocks downsample the mel and F0 features into an attention bottleneck. A mirrored decoder upsamples through four F0-gated skip connections, while the semitone shift conditions every residual block through FiLM.MODEL / PITCH U-NET STRUCTURE64 CH80 × TE1128 CH40 × T/2E2256 CH20 × T/4E3384 CH10 × T/8E4384 CH10 × T/8D4256 CH20 × T/4D3128 CH40 × T/2D264 CH80 × TD1384 CH5 × T/16ATTN BOTTLENECKMEL + F0Δ MELF0-GATED SKIP CONNECTIONSSHIFT (ST)MLP → 64-D CONDITION → FiLM IN EVERY RESBLOCK4 × DOWNSAMPLE 2 → SELF-ATTENTION → 4 × UPSAMPLE 2Pitch U-Net model architecture, simplifiedInput passes through four downsampling blocks, an attention bottleneck, and four upsampling blocks to the output. One representative F0-gated skip connection links the downsampling and upsampling paths.MODEL / PITCH U-NET
  1. 01

    Data Science Intern

    Dr. Koffer New York · Moscow

    Built forecasting and allocation tools for the logistics team, contributing to a reported 15% reduction in costs. I also built a Telegram bot that gave managers up-to-date product metrics and charts.

KCL RACING / FORMULA STUDENT

Writing firmware for KCL Racing’s steering-wheel electronics.

I programmed STM32 firmware in low-level C for a display embedded in the steering wheel, while working on reliable fuel-level tracking and the control logic around acceleration during electronic downshifts.

The firmware depended on decisions from the engine and powertrain teams. I turned those discussions into timing, sensor, actuator, and failure-state requirements, then fitted the work into a deterministic loop on one microcontroller core.

KCL Racing steering-wheel electronics blueprintAn STM32 firmware loop connects steering-wheel controls, fuel and drivetrain signals, an embedded driver display, and electronic downshift actuation, with reliability constraints around every path.KCL RACING / STEERING ELECTRONICS / SYSTEM STUDYDRIVER DISPLAYGEAR 4+STM32LOW-LEVEL C / 1 COREFUEL SIGNALFILTER / ESTIMATEDRIVER INPUTSPADDLES / STATEDISPLAYFAST FEEDBACKDOWNSHIFTACTUATION LOGICBOUNDED LOOPSENSOR NOISEFAIL-SAFE OUTPUTSWATCHDOG / RECOVERY
PLATE / STEERING ELECTRONICSFUNCTIONAL SYSTEM BLUEPRINT
  1. 01
    Design for physical uncertainty

    Fuel moves under braking and cornering; readings need filtering, sanity checks, and behaviour that remains useful when the signal is imperfect.

  2. 02
    Make time and failure explicit

    On one core, every task competes for a bounded budget. Display refreshes and control paths must be scheduled deliberately, with safe outputs and recovery treated as part of the design.

  3. 03
    Agree on boundaries first

    Electronic shifting crosses firmware, mechanical behaviour, engine response, and driver expectations. We had to agree on those boundaries before encoding them.

The main lesson was practical: reliability came from lots of small decisions about timing, bad sensor data, safe outputs, and recovery.
  1. 01

    BSc Computer Science

    King’s College London

    Currently studying.

  2. 02

    Foundation in Mathematics and Computer Science

    King’s College London

    83% overall · 89% Computer Science · 86% Mathematics for Natural Sciences.

MODULES Artificial intelligence · Operating systems and concurrency · Data structures · Databases · Robotics · Computer systems · Signals and systems · Machine Learning · Data Science · Optimization Methods · Compilers and Formal Languages · Cryptography

ADDITIONAL King’s Quant Academy · Associate Data Scientist in Python, DataCamp, June 2024

The tools and engineering areas I’ve worked with across these projects.

01

Backend

  • FastAPI and RustProduct workflows · calculation services
  • PostgreSQLTransactions · rebuildable views
  • OpenAPI and protobufREST · gRPC · generated clients
  • AuthenticationEd25519 · JWKS · scoped JWTs

02

Reliability and testing

  • Reproducible runsCode · data · engine · seed
  • Isolated workersNetwork blocks · resource limits
  • RecoveryDirty watermarks · retryable rebuilds
  • Deployment checksCI · migrations · Playwright

03

Performance

  • Database queries347 ms → 1.05 ms measured
  • Batching and cachingSparse MGET · write-back quotes
  • Atomic updatesLua-backed token rotation
  • Infrastructurek3s · Helm · Terraform

04

Quantitative software

  • Portfolio accountingTransactions · holdings · TWR
  • BacktestingSeeded runs · parameter sweeps
  • Market dataMultiple sources · live updates
  • Poker engineEquity · legal actions

05

Embedded and ML

  • STM32 firmwareBounded loops · sensors · control
  • Signal processingMel spectrograms · F0
  • Audio modelsU-Net · FiLM · training
  • Audio resynthesisHiFi-GAN · Demucs

06

Languages spoken

  • EnglishFluent
  • RussianNative
  • SpanishProfessional
01 / Backend
  • FastAPI and RustProduct workflows · calculation services
  • PostgreSQLTransactions · rebuildable views
  • OpenAPI and protobufREST · gRPC · generated clients
  • AuthenticationEd25519 · JWKS · scoped JWTs
02 / Reliability and testing
  • Reproducible runsCode · data · engine · seed
  • Isolated workersNetwork blocks · resource limits
  • RecoveryDirty watermarks · retryable rebuilds
  • Deployment checksCI · migrations · Playwright
03 / Performance
  • Database queries347 ms → 1.05 ms measured
  • Batching and cachingSparse MGET · write-back quotes
  • Atomic updatesLua-backed token rotation
  • Infrastructurek3s · Helm · Terraform
04 / Quantitative software
  • Portfolio accountingTransactions · holdings · TWR
  • BacktestingSeeded runs · parameter sweeps
  • Market dataMultiple sources · live updates
  • Poker engineEquity · legal actions
05 / Embedded and ML
  • STM32 firmwareBounded loops · sensors · control
  • Signal processingMel spectrograms · F0
  • Audio modelsU-Net · FiLM · training
  • Audio resynthesisHiFi-GAN · Demucs
06 / Languages spoken
  • EnglishFluent
  • RussianNative
  • SpanishProfessional

What I’m working on now.

Current builds and experiments.

  1. 01ACTIVE DEVELOPMENT

    Working on The Portfolio App

    I’m adding risk and tax calculations, broker connections and multilingual support. Mobile apps are planned next.

  2. 02RELEASE

    Preparing OpenQuant for an alpha release

    I moved backtest snapshots to persistent storage and finished work on CI, runtime limits and release automation.

  3. 03ACTIVE QUESTIONS

    Can pitch shifting preserve timbre?

    I’m comparing a pitch-conditioned U-Net with an ungated version on speech and music, then testing whether a transformer preserves formants more accurately.

How I work.

I usually begin by mapping the states, constraints, and failure cases. Then I build enough instrumentation to check whether the design works in practice. I’ve used that process in portfolio software, backtesting tools, embedded firmware, and audio ML.

  1. 01Understand the problem

    Learn the rules and failure cases before settling on an API or data model.

  2. 02Make it inspectable

    Add logs, metrics, and interfaces that show what the system is doing.

  3. 03Measure, then refine

    Use the results to decide what to simplify or optimise.

Iterative engineering loopA circular process connects understanding, structuring, measuring, and refining a system.01020304UNDERSTANDSTRUCTUREMEASUREREFINE
ENGINEERING LOOP / EVIDENCE BEFORE ORNAMENT

07 / CONTACT

Get in touch.

I’m looking for software engineering roles, especially in backend, quantitative, or data-heavy teams.