Computer science and 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.

Price-history query latency, before and after continuous aggregatesA logarithmic bar chart comparing a measured price-history query at 347 milliseconds before optimisation and 1.05 milliseconds after, a 330-fold reduction over 1.55 million rows.FIG. 01 / PRICE-HISTORY QUERY, MEASURED347 ms1.05 ms330×FASTER1.55M ROWS / 6 SYMBOLS / 546 CHART POINTS RETURNED IDENTICALLYPrice-history query latency, before and after continuous aggregatesA logarithmic bar chart comparing a measured price-history query at 347 milliseconds before optimisation and 1.05 milliseconds after, a 330-fold reduction over 1.55 million rows.PRICE-HISTORY QUERY, MEASUREDBEFORE347 msAFTER1.05 ms330× FASTER / 546 CHART POINTS IDENTICAL
THE PORTFOLIO APP / CONTINUOUS AGGREGATESMEASURED AUGUST 2026

Selected work

Five projects: a portfolio app, a quantitative research tool, a regex puzzle game, a poker engine, and a neural pitch shifter.

01 / The Portfolio App

A portfolio tracker built across seven backend services.

A working portfolio tracker for individual and shared household accounts. It records multi-currency transactions or imports them from CSV, values holdings from live prices, and reports P&L, time-weighted returns, risk against a chosen benchmark, and UK capital gains.

Status
Functional staging
Date
October 2026
Role
Creator
services
7 deployed backend services
contracts
REST, gRPC, codegen
platform
k3s, Helm, Terraform
The Portfolio App overview for a shared virtual portfolio showing position value, today's change, invested capital, a value chart, and a holdings table with company logos, trend sparklines, daily and all-time returns, and allocation.
Public staging deploymentLive product, October 2026
Holdings11
Allocation of the staging demo portfolio. The ring is a React port of the app’s own Svelte component: each colour follows its ticker, and neighbours that would share a colour are seated apart.
The Portfolio App advanced risk analysis showing a correlation matrix of the eight largest holdings, Fama-French factor exposure for market, size, value, quality, investment and momentum, and a 10,000-path one-year Monte Carlo projection with downside, median and upside outcomes.
Advanced risk analysisLive product, October 2026
20%
One-year Monte Carlo projection of the staging demo portfolioAt 20% volatility, after 12 months: 10th percentile $1,347,334, median $1,731,944, 90th percentile $2,237,510.$1M$2M$3MNOW3M6M9M12M
Downside, p10
$1,347,334
Median, p50
$1,731,944
Upside, p90
$2,237,510
Geometric Brownian motion over 10,000 seeded paths and 48 steps, drifting at a 4% risk-free rate rather than the portfolio’s past return. It is the same model the app’s risk service runs, starting from the staging demo portfolio’s value. The shaded bands run from the 10th to the 90th and the 25th to the 75th percentile.
The Portfolio App UK capital gains view for the 2026/27 tax year showing allowance used, the steps from realised gains to taxable gain at the basic and higher rates, and a table of disposals matched under the same-day, 30-day and Section 104 rules.
UK capital gainsLive product, October 2026

Capital gains matching, step by step

HMRC helpsheet HS284 (2025), Example 2. HMRC's answer is a loss of £1,850.

Sold 4,000 for £6,000. HMRC decides which shares were sold, in a fixed order.

  • 30-day rule, bought 11 Sep 2024500£850
  • Section 104 pool3,500£7,000
Proceeds
£6,000
Allowable cost
£7,850
Gain
−£1,850

Pool at the end of the day: 6,000 shares, £12,000 cost

Engine output computed at build time.

Six measured results from the current build.

Select a result to see where it happened. Hover, tab to or tap a service to trace it.

STAGING / SEVEN-SERVICE CONTRACT GRAPHREST, PUBLIC AND INTERNALINTERNAL gRPC, GENERATED FROM PROTOBUFFASTAPI SERVICESRUST SERVICESDATA PLANEMARKET DATASVELTEKITWEB / BFFAPI GATEWAYFASTAPI / AUTHPORTFOLIOLEDGER / NAVRISKNUMPY / STATSMODELSBROKER SYNCIBKR FLEXPRICINGTONIC / QUOTESCALCPOLARSTAXUK CGT ENGINENEONPOSTGRESUPSTASHREDISTIMESCALEDBPRICE HISTORYCLOUDFLARE R2REPORTS / BACKUPSTWELVE DATALIVE QUOTESTERRAFORM → HETZNER → k3s → HELMCLOUDFLARE EDGE / DOPPLER SECRETSSEVEN-SERVICE CONTRACT GRAPHFASTAPI / RESTRUST / gRPCSVELTEKIT WEBAPI GATEWAYPORTFOLIORISKBROKER SYNCPRICINGCALCTAXDATA PLANENEON POSTGRESUPSTASH REDISTIMESCALEDBR2 REPORTSTWELVE DATA LIVE QUOTES

Seven services behind one gateway. Python owns the ledger, risk and broker sync; Rust owns quotes, calculations and tax.

Technical details
  1. BOUNDARIES

    FastAPI services run the gateway, ledger, risk analytics and broker sync. Rust services handle quotes, portfolio calculations and UK tax matching. The public API uses OpenAPI; the Rust services are reached over gRPC using protobuf.

  2. 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. SECURITY

    The gateway signs tokens with Ed25519. Internal Python services validate them from the public JWKS and accept audience-scoped service tokens that expire after 60 seconds. Broker credentials are encrypted at rest with AES-256-GCM.

  4. 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.

Risk and tax are live on staging. Broker sync is next.

  1. Risk analytics, shipped

    The Risk view reports volatility, max drawdown, 95% historical VaR and CVaR, Sharpe and Sortino ratios, and beta against one of five benchmarks, with MSCI ACWI as the default. An advanced tier adds a correlation matrix, Fama-French five-factor and momentum exposure, and a 10,000-path Monte Carlo projection. The worst-case full report, 50 instruments over 1,299 trading days, computes in 62.4 ms.

  2. UK capital gains, shipped

    A stateless Rust tax service applies HMRC same-day matching, the 30-day bed-and-breakfast rule and Section 104 pooling. It is checked by property-based tests and HMRC manual worked examples, and it matched an independent calculator exactly on four cases. Tax-year reports export as PDFs archived to R2.

  3. Broker connections, next

    The Interactive Brokers connector is built and deployed but switched off until it has been checked against a real statement. Trading 212 sync and production Google and Apple sign-in follow.

02 / OpenQuant

Run reproducible backtests, then test whether the result holds up.

A free, open-source research workspace you host yourself. You write a strategy in Python, backtest it, then check whether the result survives trading costs, an unseen holdout period and small parameter changes. Each run is identified by a hash of its code, parameters, data version, engine version and random seed.

Status
Pre-release alpha
Date
October 2026
Role
Creator, full-stack engineer
data
4 sources, up to 50 symbols
checks
Costs, holdout, walk-forward
metrics
31 per backtest
Result
1,173 backend and 1,052 frontend tests passing. The first tagged release is waiting on clean-machine checks of the amd64 and arm64 images.
OpenQuant chart workspace showing a one-year daily AAPL candlestick chart with volume, interval, range and data-source controls, and a watchlist of stocks and crypto pairs.
Market research workspaceReal product capture, October 2026
Strategy
Costs
Training and holdout returns on OpenQuant’s synthetic datasetHoldout is the last 30% of the data. Training return +24.5%, holdout return −5.1%, buy and hold over the holdout −13.2%.−20%0%+30%REGIME CHANGESTRAININGHOLDOUT, LAST 30%
Training return
+24.5%
Holdout return
−5.1%
Buy and hold, holdout
−13.2%

Lookback picked on the training part: 6 bars.

OpenQuant’s own engine (v1.0.0) on its built-in synthetic dataset: 360 daily bars of trends, then faster reversals. This is not market data. Each holdout is a separately funded account; drag the divider or use the slider to move it.
Technical details
  1. DATA

    Research can use Yahoo Finance, Binance, Twelve Data or local CSV files, with portfolios of up to 50 symbols. A data-quality check blocks a run before it starts if the bars are out of order or contain invalid prices.

  2. RUNS

    Grid search runs every declared combination; seeded random search runs up to 10,000 trials. Strategy code runs without network access, behind an import allowlist, and under CPU and wall-clock limits.

  3. ROBUSTNESS

    A robustness suite reruns a strategy with trading costs and 2× and 3× cost stress, on a chronological holdout, across one-parameter sensitivity and a three-window walk-forward, with SHA-256 provenance on every report.

  4. NOTEBOOK

    An experiment notebook keeps names, tags, notes, a baseline and research decisions for each run, and run comparisons show what changed between two results. Saved runs are private to each account.

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 / Regex golf

A puzzle game that teaches regular expressions. Shortest pattern wins.

A minimal puzzle game, now live on the web. A 15-lesson tutorial of 22 levels teaches the syntax. Then courses of nine holes, and a daily puzzle that is the same for everyone, ask for the shortest pattern that matches one list of strings and none of another. One TypeScript codebase ships as a static site and, through Capacitor, as iOS and Android apps.

Status
Live on the web, app stores next
Date
October 2026
Role
Creator
platforms
Web (live), iOS, Android
content
22 levels, 3 courses, a daily
stack
TypeScript, Vite, Capacitor
Result
Live at regex-golf.babarika.dev, with a new daily puzzle every day. The tutorial, three courses and four weeks of daily puzzles are signed off. On the web build, Lighthouse scores 100 in all four categories on mobile and desktop, and axe-core finds no WCAG 2.2 AA violations on any screen.

Tutorial, level 1. Write a pattern that matches every string under Match these and none under Not these. The shortest pattern wins. Matching is case-sensitive and can happen anywhere inside a string, so cat finds cat inside concatenate.

0 chars, par 3

Match these

  • cat
  • concat
  • bobcat

Not these

  • bat
  • car
  • cot
  • dog

Playable levelThree puzzles from the game, with its sounds
Technical details
  1. MATCHER

    Patterns run in a Web Worker with a 50 ms limit. A pattern that backtracks past it is stopped by terminating the worker, and the game reports it as too slow instead of freezing.

  2. PAR

    Par is the length of a fair answer; on course holes the record is the shortest answer known. Search tools, including a bottom-up synthesiser in C, hunt for tricks that beat them, and the tests try every pattern of up to three characters on each level and hole.

  3. SOUND

    Typing plays a recording of a real mechanical keyboard, 27 strokes each cut to start on its click. It is encoded with LAME because Safari only skips an MP3’s encoder delay when LAME made the file; without that, every click started 12 ms late.

  4. DAILY

    The daily puzzle is picked by date, so everyone gets the same one without a server. Results are saved by date too, so the calendar, the streak and the stats all come from the save.

04 / Poker TUI

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
Complete and maintained
Date
2025
Role
Creator, Rust engineer
system
Game engine, TUI
focus
State and probability
stack
Rust, Ratatui
Result
Includes the game engine, terminal UI, bots, equity estimates and client/server play. The image below is an illustration, not a product screenshot.
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
Rules, state, and probabilityIllustrative hand state
Technical details
  1. CORE

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

  2. STATE

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

05 / Neural Pitch Shifter

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
Experimental, no validated result yet
Date
August 2026
Role
Creator, ML engineer
system
Audio pipeline
focus
Pitch and timbre
stack
PyTorch, DSP
Result
The pipeline is implemented, but training and model comparisons are still in progress. The diagram shows the intended signal flow.
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
Conditional audio transformationIllustrative signal pipeline
Technical details
  1. MODEL

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

  2. 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

Experience

  1. 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 / RECOVERYKCL Racing steering-wheel electronics, simplifiedFuel signal and driver paddle inputs feed an STM32 running a bounded loop in low-level C, which drives the steering-wheel display and the electronic downshift actuation.STEERING ELECTRONICS / SYSTEM STUDYFUEL SIGNALFILTER, ESTIMATEDRIVER INPUTSPADDLES, STATESTM32LOW-LEVEL C, 1 COREDRIVER DISPLAYFAST FEEDBACKDOWNSHIFTACTUATION LOGICGEAR 4BOUNDED LOOPOne core, fixed budgetSENSOR NOISEFilter and sanity-checkFAIL-SAFE OUTPUTSKnown state on faultWATCHDOGRecover without a reset
Steering electronics, functional system blueprint
  1. 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. 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. 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.

Reliability came from lots of small decisions about timing, bad sensor data, safe outputs, and recovery.

Education

  1. BSc Computer Science

    King’s College London

    In progress, graduating 2027. Coursework covers systems, machine learning, and optimisation.

  2. Foundation in Mathematics and Computer Science

    King’s College London

    83% overall. 89% in computer science, 86% in mathematics for natural sciences.

Systems

  • Operating systems and concurrency
  • Computer systems
  • Compilers and formal languages
  • Databases

Theory and maths

  • Data structures
  • Optimization methods
  • Cryptography
  • Signals and systems

Applied AI

  • Artificial intelligence
  • Machine learning
  • Data science
  • Robotics

Additional

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

Technical profile

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

Backend

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

Reliability and testing

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

Performance

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

Quantitative software

  • Portfolio analyticsTWR, VaR, factor models, UK CGT
  • BacktestingSweeps, holdout, walk-forward
  • Market dataMultiple sources, live updates
  • Poker engineEquity, legal actions

Embedded and ML

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

Languages spoken

  • EnglishFluent
  • RussianNative
  • SpanishProfessional

What I’m working on now.

Current builds and experiments.

  1. Building

    Connecting brokers to The Portfolio App

    Risk analytics, UK capital gains reports and five languages are live on staging. Next I’m switching on Interactive Brokers sync, then adding Trading 212 and production sign-in.

  2. Releasing

    Preparing OpenQuant for its first release

    I added robustness checks, an experiment notebook and private saved runs. The release workflow publishes signed amd64 and arm64 images once clean-machine tests pass.

  3. Researching

    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. Understand the problem

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

  2. Make it inspectable

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

  3. Measure, 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

Get in touch.

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

Email me

aleksandr@babarika.devLondon, United Kingdom