Paper to Live, Capstone, and Crypto

This is where everything comes together: taking a strategy you believe in (because you backtested it honestly, Lesson 10, with real costs, Lesson 12) and running it for real — carefully. The gap between a good backtest and a working live system is where most retail traders get hurt, not because their idea was wrong but because they rushed from simulation to real money with no gates, no monitoring, and no plan for when live reality differs from the backtest (which it always does). We’ll end with a capstone that ties the whole course into one system, and with how to reuse that system on crypto.

From Backtest to Live, Through Gates

The cardinal rule: never jump straight from a backtest to real money. Promote a strategy through a series of gates, each of which can send you back if it fails.

The gates:

1. Backtest — on clean historical data, with realistic costs and slippage (Lessons 10, 12) and honest fills (Lesson 4). This rejects most ideas for free.
2. Paper / sim — run the strategy on live market data but with simulated fills and no real money. This is where the broker-adapter design (Lesson 9) pays off beautifully: swap the live adapter for a mock adapter that simulates fills, and the exact same strategy code runs against live data. Paper trading catches bugs, surfaces real-world data issues (Lesson 3), and shows how the strategy behaves on current markets — all risk-free.
3. Live, tiny size — real orders, at the smallest size possible. Now you’re exposed to the things simulation can’t fully capture: real slippage, real latency, partial fills, real broker behaviour. Keeping size tiny makes this stage cheap tuition.
4. Scale slowly — increase size only as the strategy proves itself live, gradually, never in one jump.

The reason for the gates is one unavoidable truth: live always differs from the backtest. Slippage is worse than you modelled, latency delays your fills, orders fill partially, the broker rejects something, the data gaps. Each gate exposes a different slice of that reality before you’ve risked much. Rushing the gates is the single most expensive mistake in this whole course.

Running It for Real: Monitor and Review

Once a strategy is live, two activities keep it safe and honest: monitoring (watching it in real time) and post-trade analysis (studying it after).

Monitoring answers, continuously: Is the strategy alive and is its data flowing? Are orders actually filling? What’s the live P&L? Are we near a risk limit? Build this into your dashboard (Lesson 8’s React UI) and alert on the danger signs — a disconnected feed or data gap (Lesson 3), a broker error, P&L approaching the daily-loss limit. And keep the kill switch armed (Lesson 8), with automatic triggers, so a problem detected at 2 PM doesn’t require you to be watching. A live algo you’re not monitoring is how silent failures become large losses.

Post-trade analysis is the review that makes you better and catches decay:

• Measure real slippage — compare the price you expected (the signal price) to the price you actually got, across many trades. This tells you your true costs (Lesson 12) and whether they match your backtest assumptions. If real slippage is worse than modelled, your edge may be smaller than you thought.
• Reconcile everything — every order and fill against the broker’s record, using PostgreSQL as your source of truth (Lesson 8). You must always know your true position and P< discrepancies are bugs or problems to chase immediately.
• Watch for strategy decay — edges erode as markets change and others find them (Lesson 2). Track whether the live performance still matches the backtest; a persistent divergence is a signal to investigate or retire the strategy.

Monitoring keeps you safe now; post-trade analysis keeps you honest and improving over time. Both rely on the durable record (Postgres) and the discipline to actually look at it rather than hope.

The Capstone: an End-to-End Mini System

Everything in this course assembles into one coherent system, and building a small version of it is the capstone. The data path flows: market data → order book → strategy → risk checks → broker, wrapped in a dashboard and a kill switch — which is precisely the architecture of Lesson 8, scaled down to a single strategy:

• Data comes in over a WebSocket through your broker adapter (Lessons 3, 9), with reconnect/resync handled.
• You maintain an order book / the price state your strategy needs (Lessons 3, 4).
• A strategy (Lesson 11) computes signals on that data — something simple, with a nameable edge, at a slow-enough horizon for retail (Lessons 2, 6).
• Every order passes pre-trade risk checks (Lesson 8) before going out.
• Orders go to the broker via the adapter; fills come back, the OMS tracks state, and everything durable is written to Postgres (Lesson 8).
• A dashboard shows live state and P< a kill switch can stop everything instantly.

Run it first in paper mode (mock adapter), then live tiny, following the gates above. Even a minimal version of this — one simple strategy, end to end, with real risk controls and monitoring — teaches you more than any amount of reading, because it forces you to confront every real-world detail the earlier lessons warned about.

The Same Framework on Crypto

A final payoff of building things cleanly: your whole system extends to cryptocurrency trading with surprisingly little change.

What carries over — nearly everything: the whole architecture (Lesson 8); order-book and matching concepts and the low-latency building blocks like ring buffers (Lessons 4, 5); your strategy logic and, crucially, your backtesting discipline (Lesson 10); your cost and slippage thinking (Lesson 12 — crypto fees still bite); and your risk checks, kill switch and monitoring (Lesson 8). To trade a crypto exchange, you mostly just write a new exchange adapter (Lesson 9) implementing the same interface.

What’s genuinely different — mind these:

• 24/7 markets. Crypto never closes, so your system must run and self-heal around the clock — no overnight window to restart and fix things. Monitoring and automatic recovery matter even more.
• Many venues, fragmented liquidity. Liquidity is spread across many exchanges, with real differences between them.
• Variable API quality and downtime. Exchange APIs range from excellent to flaky; downtime and rate-limit quirks are common, so your adapter’s resilience is tested harder.
• Key custody and security is on you. Holding crypto means holding private keys — a serious security responsibility (lose or leak them and the funds are gone). This is a whole discipline the stock-broker world handles for you.
• Lighter regulation ≠ lower risk. Fewer rules mean more scams, more counterparty risk, and more ways to lose money, not fewer. Treat the reduced regulation as increased danger.

The point stands as the reward for everything you’ve built: because you programmed against a clean broker-adapter interface, moving a strategy to crypto is mostly a new adapter plus operational changes — not a rewrite. The same engine, the same risk controls, the same discipline apply across asset classes. That’s what good architecture buys you. And the caveat worth repeating as this course closes: crypto is highly volatile and lightly regulated — the same discipline applies, but the danger is greater.

Pitfalls to Avoid

1. Jumping from backtest straight to live. Promote through gates — backtest → paper → live tiny → scale slowly — each able to send you back.
2. Expecting live to match the backtest. It won’t: real slippage, latency, partial fills, broker quirks. The gates exist to expose these cheaply.
3. Running a live algo without monitoring. Silent failures become big losses. Monitor liveness, data, fills, P&L and risk limits; alert; keep the kill switch armed.
4. Not reconciling or measuring real slippage. Reconcile every fill against the broker (Postgres as truth) and compare expected vs actual prices, or you won’t know your true position or costs.
5. Ignoring strategy decay. Edges erode. Track live-vs-backtest divergence and retire strategies that stop working.
6. Treating crypto as “just another market.” 24/7 operation, key custody, flaky APIs and lighter regulation make it riskier. Reuse the framework, respect the differences.
7. Forgetting this is educational, not advice. A working system still loses money sometimes; markets (and crypto especially) can take all of it.

Quick Recap

• Promote through gates: backtest (with costs) → paper/sim (mock adapter, live data, no real money) → live tiny → scale slowly; each can send you back, because live always differs from the backtest.
• Running live needs monitoring (liveness, data, fills, P&L, risk limits; alerts; armed kill switch) and post-trade analysis (real slippage, reconciliation via Postgres, decay).
• The capstone is the whole course as one system: data → book → strategy → risk → broker, with a dashboard and kill switch — Lesson 8’s architecture, scaled to one strategy.
• Crypto reuses nearly everything (a new adapter, Lesson 9); mind the differences — 24/7, key custody, flaky APIs, lighter regulation = more danger.
• Educational, not financial advice — a working system can still lose, and markets can take all of it.

That’s the course. You now understand electronic markets from the order book up, the engineering that makes trading systems fast, a real architecture to build one, and — most importantly — the honest discipline (backtesting, costs, risk, psychology) that decides whether an algo survives. Go build a small one, run it on paper, and keep learning. Trade carefully, size for survival, and never risk what you can’t afford to lose.