There’s a whole industry of backtesting libraries, tutorials, and arguments about the right way to do it. The attention makes sense, the backtest is the first place you find out whether an idea has legs. But it’s worth saying plainly: of all the steps between an idea and a live trading system, the backtest is the easy one.
Why the backtest is easy
Not easy to do well, easy in the sense that it’s the most controlled, most forgiving environment you’ll ever run your strategy in. The data is complete and sitting in a file. Time moves at your command. There’s no broker to reject your orders, no real-time gaps, no position from yesterday, no account that disagrees with you. You can run it a hundred times and tweak until it looks great.
That control is exactly what makes a good backtest result mean less than it feels like it does. You optimized inside a sandbox where almost everything went your way.
Where the hard part lives
The hard part is everything the backtest got to skip:
- Real-time data that arrives messy and late.
- Orders that fill at worse prices, partially, or not at all.
- A broker that’s the actual source of truth for your positions and buying power.
- A calendar full of holidays, half-days, and expirations.
- A long-running process that has to stay up and be monitored.
- A way to know what happened, and a way to stop it when it goes wrong.
These don’t show up in research. They all show up the moment you go live, together, and they’re where strategies actually fail.
The reframe
If you’ve spent ninety percent of your effort on the backtest, you’ve spent it on the easy ten percent of the problem. That’s not an argument against backtesting, you still have to do it, and do it honestly. It’s an argument for taking the rest seriously: the fills, the broker state, the calendar, the monitoring, the operations.
The strategies that make it aren’t the ones with the prettiest backtest. They’re the ones whose authors treated the backtest as the start of the work, not the end of it.