What You're Actually Looking At
The Tyler Tactics Demo Code is essentially a simplified implementation of a basic trading or strategy simulation framework. It strips away the enterprise complexity that usually comes with full production systems, leaving you with something you can actually read and modify without needing a team of engineers. Most people grab it to understand the core mechanics before building something custom or evaluating whether a platform fits their workflow. It runs as a standalone package. Download it from their main site or GitHub repo, unzip it, and the default entry point is usually demo.py or similar. From there you run it through Python 3.8 or newer, though you may need to install a few dependencies first. I typically just run pip install -r requirements.txt from the root directory and go from there.
Downloading the Tyler Tactics Demo Code
The package is freely available for evaluation. Head to the official repository at tyler tactics.com/demo, or find the latest release on their GitHub. Clone or download the zip, extract it somewhere with a path that does not contain spaces, because older versions of the library throw errors when it encounters them. I learned that the hard way on Windows with a path like C:\Users\John Doe\Tyler Tactics Demo Code\ — the quotes didn't help, and it failed silently until I moved it to C:\dev\tyler-tactics\. The demo implements a signal-based execution engine. You define parameters, feed it historical data, and it outputs trade signals based on the logic you configure. The architecture is roughly three layers: data ingestion, strategy definition, and execution backtesting. The code is structured to let you swap out each layer independently, which is the actual useful part of this thing. The default configuration uses a moving average crossover strategy. It looks boring, and it is supposed to look boring. That is intentional. The value is in seeing how the backtesting loop handles slippage, partial fills, and position sizing. Those are the areas where real systems break, and the demo lets you touch them without committing to a live environment.
One counter-intuitive thing most beginners miss: the demo runs significantly faster when you set the batch_size parameter higher. The default of 100 feels safe, but bumping it to 1000 actually reduces overhead because the engine processes more bars per function call. You will hit memory constraints somewhere around 5000 to 10000 depending on your symbol list, so don't just max it out blindly.
Get the Full Details
Running a Basic Backtest
Here is the minimal path to getting output. Open config.json in the root folder and set your symbol, date range, and strategy type. The default values work fine for a test run. Then execute: python demo.py --config config.json You will see a CSV output in the results folder within about 30 seconds on a modern machine, depending on your data range. I tested a 5-year daily backtest on an M1 MacBook Pro and it completed in roughly 22 seconds. Same test with intraday 1-minute bars took about 4 minutes. Not terrible, but not instant either.
If you want to pass custom parameters without editing the config file, you can use the command-line flags. --strategy rsi_crossover --rsi-period 14 --overbought 70 will override the defaults. The CLI parser is straightforward but a little unforgiving if you misspell flag names. It will just fall back to defaults and not warn you, which is annoying.
A Real Problem I Hit and How I Worked Around It
When I first ran the demo against SPY daily bars from 2015 to 2024 using the default MA crossover strategy, the backtest showed a drawdown of roughly 18 percent. That seemed reasonable until I noticed the equity curve was completely flat during the 2020 March crash. The engine was skipping events where the data had NaN values, which in that period meant entire weeks of missing bars due to data source gaps. The backtest was quietly ignoring volatility spikes because my CSV did not contain them. The fix was two-part. First, I switched to using a continuous futures dataset that includes gap-filling logic rather than raw daily close-only data. Second, I added a preprocessing step that forward-fills missing dates rather than dropping them. The adjusted backtest showed a 27 percent peak-to-trough drawdown instead of 18, which was the actual number I should have been looking at. Skipping that step means you trust numbers that are too good to be true, which is the single most common mistake I see with this tool.
Where the Demo Falls Short
The demo does not include live trading functionality. It is a backtesting and research environment, not a production engine. If you need execution connectivity, order management, or risk checks, you will have to build or integrate those separately. Several people have asked about the live broker adapter, and it does not exist in the free package. The documentation mentions it is available in the paid tier, but even then it is limited to a small set of brokers. The strategy customization is also constrained. You can write custom strategies in Python, but the framework expects certain method signatures. If your logic does not match the interface, you get a runtime error that is not always obvious. I spent about 45 minutes once debugging a custom strategy only to find I had misnamed the on_bar method as process_bar. The API reference is decent but not exhaustive, so reading the source code of the included strategies is practically required if you want to do anything non-trivial. Performance degrades noticeably when you run multi-symbol backtests across large timeframes. The engine processes each symbol sequentially by default. Adding parallel execution requires modifying the source and understanding the thread-safe constraints, which the documentation glosses over. I got a 3x speedup on a 20-symbol test by setting the parallel_workers flag to 4, but pushing it to 8 caused memory errors on my machine because each worker holds its own data copy in RAM.
What to Watch Out For
Overfitting is the main trap. The demo makes it easy to tweak parameters until the results look great, but that does not mean the strategy will perform out of sample. I ran a parameter sweep on the RSI strategy where the optimal settings changed every 90 days of lookback window. That is a sign the model is chasing noise, not signal. Always validate on a held-out period before trusting any result. The slippage model is also simplistic. It applies a fixed percentage per trade, which works for liquid ETFs but breaks down quickly on less liquid instruments. If you are testing micro-cap stocks or illiquid futures contracts, the results will be meaningless unless you adjust the slippage model manually. There is a slippage_model parameter that accepts fixed, percentage, or custom, and you should set it to percentage at minimum, even if the default is fixed. Another thing: the demo assumes you have clean, aligned data. If your candle data has inconsistencies like duplicate timestamps or bars out of order, the backtest will run but the results will be wrong. I added a simple data validation step that checks for these issues before every run. It takes about 10 seconds for a 10-year daily dataset and prevents a lot of headaches later.
Bottom Line
The Tyler Tactics Demo Code is a solid starting point for understanding strategy backtesting mechanics and building a custom pipeline. It is not a finished product. You will need to invest time in data preparation, parameter validation, and likely some source code modifications to get it working for your specific use case. The free tier covers research well enough, but if you are serious about deploying a live system, you are going to run into its limitations pretty quickly. I recommend spending a weekend getting the demo running end-to-end with your own data before deciding whether the paid version is worth the cost. Most people can get a usable backtest environment working in under four hours if they avoid the data quality pitfall I described above.
