Most Python trading strategies never make it to live. Not because the idea was bad, but because the path from a backtest in a notebook to a monitored live run is longer and more fragile than it looks. This guide walks that path and points out where it usually breaks.
The whole journey has three stages, backtest, paper, live, and the goal is to change as little as possible between them.
Stage 1: Backtest on historical data
A backtest replays historical market data and runs your strategy against it, recording what would have happened: every order, fill, position, and the resulting P&L.
Two things matter more than the headline return:
- Use an event-driven backtest, not a vectorized one. An event-driven engine feeds your strategy one market event at a time and lets it react, the same shape as live execution. Vectorized backtests compute over whole arrays at once; they’re fast, but they make it easy to accidentally use information your strategy wouldn’t have had yet.
- Model the costs. A fill at the last printed price is a fantasy. You want spread and slippage modeled so the backtest’s fills resemble what a real order would get.
Stage 2: Paper trade on a live feed
Paper trading runs the same strategy on a live market feed, but routes orders to a simulator instead of a real broker. No capital is at risk.
This stage exists to catch everything a backtest can’t:
- Does the strategy place the orders you expect, at the times you expect, over a real session?
- Does it handle a slow open, a data gap, or a quiet afternoon the way you assumed?
- Does anything time out, throw, or quietly do nothing?
Paper is where most strategy bugs actually surface, because it runs in real time against real data.
Stage 3: Go live, carefully
Live runs the same code against a real broker. The strategy doesn’t change; the broker binding does.
Going live should be a deliberate step, not a toggle you flip on a whim. In live, your broker is the source of truth for fills, positions, and buying power, your software observes and records, but the account is real and so are the consequences.
What changes between stages, and what shouldn’t
The discipline of the whole path is captured in one rule: the strategy code should not change between backtest, paper, and live. What changes is underneath it:
| Data feed | Order fills | |
|---|---|---|
| Backtest | Historical | Simulated by a fill model |
| Paper | Live, real-time | Simulated by a broker sim |
| Live | Live, real-time | Real broker |
If you find yourself maintaining a separate “live version” of the strategy, that’s the bug. Every difference between research code and production code is a place for behavior to drift.
Common ways the path breaks
- Look-ahead bias. The backtest used data the strategy wouldn’t have had in time. Live can’t reproduce the result.
- Unmodeled costs. The backtest assumed perfect fills; live pays the spread and slippage.
- Order types that don’t translate. Some order types you lean on in live may not be modeled the same way in a backtest. Know which ones, and don’t assume a stop behaves identically.
- Calendar and session bugs. The strategy traded at times the market was closed, or mishandled an early close or a futures expiration.
- Broker state surprises. The account wasn’t flat when the run started, or buying power wasn’t what the strategy assumed.
What to inspect before each promotion
Before moving a strategy from one stage to the next, look at the behavior, not just the return:
- The orders: did it place what you expected, and were any rejected?
- The fills: at what prices, and how far from your assumptions?
- The positions and ledger: did exposure and cash move the way they should?
- The logs and issues: did anything warn, error, or fire that you didn’t expect?
If those line up across backtest and paper, you have a strategy that’s earned a careful look at live.
How Periscøpe handles backtest → paper → live
Periscøpe is built around this exact path. You write the strategy once in Python, and a run’s mode, Backtest, Paper, or Live, is a setting, not a separate program. The same strategy version runs in all three; only the data feed and broker change underneath it.
The backtest is event-driven and models spread and slippage with real market calendars. Paper runs it on a live feed with simulated fills. Live runs it through your broker, with access rolled out to select users on request. And every run, in any mode, gives you the orders, fills, positions, ledger, issues, and logs you need to compare the stages and trust the promotion.