Aldrich Quant Bot.
An end-to-end algorithmic trading system I built to test whether classical trend and momentum still hold on US equities once realistic execution costs are on the table. Backtest engine, two live strategies, paper trades to a real broker, running unattended on a cloud server.
Do the textbook effects actually survive real execution?
Trend-following and momentum are the two most-cited effects in quantitative equity research — and also the two most-argued-about. Do they still work on US large-caps once you subtract slippage, commissions, and the operational cost of running the system day after day?
I wanted a first-hand answer, not one filtered through a book. So I built the whole loop myself: historical data in, backtest out, live paper orders sent to a real broker, cloud server running unattended. If the classical edges held under my execution assumptions, I’d see it in the equity curve. If they didn’t, I’d see that too.
Engine first, strategy second.
A bad backtest hides a bad strategy — a clean one exposes it. So the first commits went to quantbot/data.py (a versioned loader with a consistent daily-bar schema), quantbot/backtest.py (portfolio-state accounting that tracks positions, cash, and fills bar-by-bar), and quantbot/metrics.py (Sharpe, drawdown, turnover, hit rate).
Only once the engine passed its own pytest suite did I let a strategy touch it. Trend and momentum went in next as small, testable modules under quantbot/strategies/. Every strategy has to work through the same interface — no special cases, no peeking at the future.
One core. Three surfaces.
The result is a compact Python package — roughly 15 modules — that runs three surfaces off the same core.
- Research. Scripts under research/ (run_phase1.py, make_report.py, plotstyle.py) drive multi-decade backtests over 10+ years of daily bars and emit HTML reports.
- Live. quantbot/live/{config,broker,engine}.py connects to Interactive Brokers’ OpenD gateway and submits paper orders through the same signal path the backtest uses — no forked logic.
- Production. live_daily.py is a single entry point that a systemd service and timer invoke each trading day on an Ubuntu cloud box. An opend-boot service brings the gateway up before the runner fires.
The pytest suite covers the engine and both strategies, so I can refactor a data loader without holding my breath.
Runs daily, on its own.
No cron babysitting, no manual data pulls, no me-at-my-laptop-at-9:30am. Backtests validate across a decade-plus of daily bars with realistic transaction costs; live paper trades reconcile against expected fills each session.
More importantly, the codebase is a place I can actually try new ideas fast. A new strategy is one file under quantbot/strategies/, tested against the same engine, backtested against the same data, deployed through the same runner. That was the point: build the surface once, iterate forever.
The trading result is, honestly, secondary.
What this project actually taught me is production hygiene at small scale — packaging, tests, systemd units, log discipline, config isolation. The same muscles I need for a data-science role, just applied to my own bet instead of someone else’s roadmap.
A backtest will tell you whatever you want to hear. A live paper account, running for weeks against real market opens, tells you what actually happens.
That’s the discipline I’m bringing to a data-science role: research that earns its keep by running in production, not by looking clever in a notebook.
Bring this rigor to your team.
I’m interviewing for full-time Data Science and Analytics roles starting August 2026. If your team wants a builder who ships research all the way to production — not just to a slide — let’s talk.