How to start algorithmic trading

By John, builder of Wise Apple · Updated August 27, 2026

You've decided to stop clicking buy on a feeling and start testing rules instead. Then you searched "how to start algorithmic trading" and got a course, a Python tutorial that ends at a moving average, and a forum thread arguing about which broker's API is least bad. None of that is a path.

"If you had to start over, how would you learn algo trading?" is asked on r/algotrading every few weeks, usually by a working software developer or a trader who has been doing this by hand for years. The good replies agree on more than the bad ones would suggest: start slow, start small, learn to test before you learn to trade. This page turns that agreement into an order of learning, gives two realistic routes through it — one for people who write code and one for people who will not — and names the places each route stalls.

It assumes you want a tested rule you can trust, not a bot by Friday. If you want the bot by Friday, the honest answer to whether this is worth it is the page to read first.

What both paths have in common

Whether you build in Python or in a no-code tool, the discipline is identical, because the failure modes belong to the method and not the tool. Four habits, from the first day:

• One instrument, one timeframe. A single liquid stock, ETF or major crypto pair, on daily bars. Not a universe, not a portfolio, not five-minute candles. Everything is easier to see when there is one thing to look at.
• Daily bars first. Fills are close to the backtest's, costs are a small fraction of the move, and a decade of history is a few thousand rows you can actually inspect. Intraday adds latency, spread and data problems before it adds edge.
• A notebook of hypotheses. Write the rule down before you test it, with the reason you think it should work. Then write down the result, including the failures. The count of things you tried is a number you will need later.
• The honest-testing loop. Next-bar fills, real costs, a time-ordered split with a gap, walk-forward, enough trades, a sealed holdout. The backtesting guide is the loop in full; everything below is a step of it.

The order of learning

Most people learn these in the wrong order — model first, costs last — and it costs them a year. This order front-loads the parts that decide whether anything later means anything.

1. What an edge is, and where retail ones come from. Before any code: an edge is a reason someone on the other side of the trade is paying you, and for a retail trader that reason is usually patience, an unglamorous instrument, or a timeframe nobody is paid to watch. The edge guide covers how to tell one from a lucky backtest.
2. How to backtest honestly. The whole loop, once, on a deliberately boring rule such as a moving-average cross, so you learn the machinery without caring about the result. The pillar guide is the syllabus.
3. Data. Where to get it, what adjustments and gaps and survivorship do to it, and why two sources disagree. The free data guide lists sources and the five catches.
4. Costs. Spread, fees, slippage, impact. Learn the cost-multiplier test early: if 1.5× costs kills the edge, there was no edge. See realistic backtest costs.
5. Validation. Why a random split is wrong for time series, what an embargo gap is, how walk-forward works, and why the best of forty ideas always looks good. The out-of-sample and walk-forward guides.
6. Reading results. Trade count before anything else, then expectancy, profit factor, drawdown against return, the buy-and-hold benchmark. Not win rate, not accuracy. See how to read a backtest report.
7. Sizing. Fixed fraction, why full Kelly is a trap, volatility scaling. Learn it before the first live trade, not after the first live drawdown.
8. Rehearsal. Alerts only, then the smallest real size, with a kill rule written first. The go-live guide is the gate.

Machine learning is not on the list, on purpose. It is a later chapter, and it makes every earlier mistake worse — a leak in a moving-average backtest costs you a bad result; a leak in a model costs you a result that looks brilliant. When you get there, the model-families guide is the honest starting point.

Path one: the working programmer

You write code for a living, you have a Python environment, and you assume the trading part is the hard part. It is — but not the part you expect. The code is a week. The honesty is a year.

What you will build

Either a library (Backtrader, backtesting.py, vectorbt) or, more often than is wise, your own engine. Building your own teaches you every fill and cost decision explicitly, which is valuable. It also means every leak is yours to introduce silently, which is the trade-off. If you use a library, read its fill model before you trust a single number; most default to something optimistic.

Where this path stalls

• Infrastructure instead of research. Six months on a data pipeline, a dashboard and a broker integration, zero tested hypotheses. A recurring confession on r/algotrading.
• The optimistic fill. Filling at the signal bar's close — the single most common leak in home-built engines, and it makes everything look good. The leakage guide has the one-line fix.
• Model before rule. Reaching for a gradient-boosted classifier before a moving-average cross has been tested honestly. The classifier will find a pattern; you will not know if it is real.
• AI-written code you did not read. Fast to produce, and it makes the standard mistakes at speed. The AI-bot checklist is what to verify before trusting it.

Path two: the trader who will not learn Python

You have traded by hand for years, you can describe your setup in a sentence, and you tried a Python course and stopped at the third pandas error. This path is legitimate. It is also more common than the programmer path, and it is where most of the "how do I backtest without coding?" questions come from.

What you will use

A platform's strategy tester or a no-code research tool. The thing to judge it on is not the interface; it is whether it exposes the six controls that decide whether a backtest is honest — fill timing, costs, the time split, the label, the validation, and trade-level inspection. A tool that hides four of those is a toy with a chart. The no-code guide turns this into a checklist, and the local vs. cloud comparison covers the families of tool.

Where this path stalls

• The tester that cannot say no. Charting platforms' backtesters are built to show you a strategy working. Check whether yours charges costs and fills on the next bar; the TradingView limits page covers the usual gaps.
• Rules that cannot be written down. "I enter when it looks strong" is not a rule. The exercise of translating a setup into settings is itself the most useful thing this path teaches, and about half of hand-traded setups do not survive it.
• Indicator stacking. Adding a fourth filter because the third did not help. The overfitting guide explains why this always improves the backtest and never the trading.
• Trusting the tool's defaults. Whatever it assumes about fills and costs, it assumes silently. Find the settings; if there are none, that is your answer.

The two paths side by side

Neither is the serious path and the other the toy. Plenty of good research has come out of a spreadsheet, and plenty of beautiful engines have never tested a single honest hypothesis.

What not to start with

Each of these is where someone on the forums started, and each is where a post titled "where did I go wrong" came from.

• High-frequency anything. You are competing on speed with people who measure it in microseconds. Your edge, if you have one, is that you can wait.
• Options complexity. Multi-leg structures add pricing, Greeks, assignment and liquidity problems on top of the problem you have not solved yet.
• Deep learning. A few thousand daily bars is a tiny dataset, and the tutorial curves that look perfect are leaks. The LSTM guide shows the trick.
• Buying a strategy. A rule with a real edge is worth more traded than sold. Test the claim yourself, with costs, on data the seller did not choose.
• A bot before a tested rule. Automation is the easy part and the last part. Automating an untested rule just loses money faster and more consistently.

Books and courses, briefly

You do not need a course, and the good books are few. Aronson's Evidence-Based Technical Analysis (2007) will make you sceptical in the right way; Chan's Quantitative Trading (2008) is the practical retail starting point; Carver's Systematic Trading (2015) is the best thing written on sizing and system design for one person; and López de Prado's Advances in Financial Machine Learning (2018) is the one to read when you reach the machine-learning chapter, not before. The books guide covers each in the order to read them and what each one is actually for.

A first month that works

1. Pick one liquid instrument and daily bars. Get ten years of data and check it for gaps and adjustments.
2. Write down a boring rule — a moving-average cross with a fixed stop — and the reason it might work.
3. Backtest it with next-bar fills and full costs. Split time, leave a gap, seal the last two years.
4. Read the report in order: trade count, expectancy, profit factor, drawdown, benchmark. Expect it to lose. That is the point; you are learning the machinery.
5. Run the cost sweep and the one-bar shift test. Note what changes.
6. Write down what you tried, what happened, and what you would test next. That notebook is the asset.

How a start looks in Wise Apple

Wise Apple is the no-code path with the six controls exposed. It runs in the browser on your own machine, with ten-plus years of stock, ETF and crypto history preloaded and CSV import for your own data. In PowerCore Studio you define the rule without code — or write it in WiseApple Script if you prefer — and the guardrails are on by default: next-bar fills, realistic fees, slippage and impact, an Embargo Bars gap, a Walk-Forward Window, and train-only scaling. The report leads with trade count and the HODL benchmark, and every trade can be replayed candle by candle. It tests one instrument at a time and places no trades, which for a first month is the right constraint rather than a limitation. Nineteen machine-learning models are on the bench for the later chapter; they are not the place to start, and the tool does not pretend otherwise. It is early software from one builder.