A Full-Stack Systematic Trading Platform, Backtest to Live
An internal reference build: one engine that runs the same strategy code across backtest, paper, and live trading — with a real paper-trading track record to show for it.
This is an internal reference build, not a client engagement — we built it to have our own working, full-stack systematic trading platform: a small-scale system that runs the complete path from data to execution, built solo, but architected so the same code drives backtest, paper trading, and live. Specifics below are generalised.
The Challenge
Most trading systems that start life as a backtester never quite make it to production without a rewrite — the research code and the execution code drift apart, and the gap between "worked in backtest" and "works live" becomes its own project. We wanted the opposite: a platform small enough to run solo on a single machine, but architected from day one so nothing has to be rebuilt to go from research to a live book.
We also wanted it to do more than one thing well — a genuine test bed across asset classes and strategy styles, with portfolio-level risk and capital allocation across multiple strategies at once, not a single-strategy toy.
The Approach
We treated this as an architecture problem first and a trading-strategy problem second, and made a small number of deliberate, documented decisions rather than defaulting to whatever a generic tutorial suggests.
1. One engine, three modes
Strategies are written once against a single interface. The same engine drives them in backtest, in paper trading, and in live — only the data source and the broker connection change underneath. There's no separate "live version" of the logic to keep in sync, so backtest results carry directly into paper and live performance rather than needing separate reconciliation.
2. A data architecture sized to the job
Operational data — positions, orders, fills, market bars — sits in a warm, queryable operational store built for time series. A separate cold layer, fed by a nightly batch process, holds historical data for research at scale. We deliberately left out infrastructure a system this size doesn't need yet, while keeping the boundaries clean enough to add it later without a rewrite.
3. Domain model before code
Core concepts — instrument, order, fill, position — were defined and validated as explicit, typed domain objects before any strategy logic was written. Positions are modelled at both the per-strategy level and the account level, so a multi-strategy book nets correctly against the broker while still letting each strategy see its own book.
4. Portfolio and risk across strategies, not just within one
Capital allocation and risk budgeting sit above individual strategies, so multiple strategies across multiple instrument classes can run concurrently under a single portfolio-level risk view — the difference between a collection of scripts and an actual platform.
5. Build vs. adopt, decided deliberately
Rather than assume everything had to be built from scratch, we explicitly evaluated adopting existing open-source trading-engine components for the parts that don't differentiate — execution simulation, broker connectivity — against building them in-house, and documented the decision criteria and boundary before writing code either way.
Tools & Technologies
Asynchronous Python running engine, broker-gateway, market-data ingestion and persistence as cooperating tasks in a single process; a relational time-series database for operational data; a columnar store for cold research data; typed domain models validated at every boundary; containerised so the whole stack runs from a single machine but doesn't box in scaling components out later.
The Results
The platform runs a real paper-trading track record on the exact code path that would run live — there is no separate "live rewrite" step waiting at the end. Multiple strategies across instrument classes run concurrently under one portfolio and risk view, with the reconciliation and reporting to show whether the book is behaving as the research said it would.
It has since become more than an internal tool: it's the worked example we use to teach the spec-driven AI-workflow approach in our training practice — see how the same backtest-to-live parity discipline anchors our AI Workflow training case study →