Strategies rarely die from bad math. They die from a timezone bug that shifted signals by a day, an order loop that retried itself into triple position, a feed that went stale silently for a week. The gap between backtest and survival is operational, and operations respond well to checklists. This is ours — six gates, in order. Treat every unchecked box as a reason not to size up.

Gate 1 — Validation (before writing any production code)

  • ☐ Untouched out-of-sample period evaluated exactly once, after all iteration stopped. If you peeked and iterated, it’s training data now — carve a new one.
  • ☐ Cost-sensitivity curve: P&L at 1×, 2×, 3× your assumed costs. A strategy that dies at 2× costs is a cost model, not a strategy.
  • ☐ Execution-lag sensitivity: signals delayed by one bar/one minute/one hour. Fragility here predicts slippage pain later.
  • ☐ Capacity estimate: at what size does your fill assumption break? (Thin books make this the first constraint — see the prediction-market guide.)
  • ☐ Regime slices: performance in at least three distinct volatility/trend regimes, and you can articulate why it should work in the ones where it does.
  • ☐ Sample-size honesty: trades clustered by underlying event/period counted as clusters, not independent observations.

Gate 2 — Code

  • ☐ One signal implementation. The backtest and live system import the same signal function from the same module. Reimplementing “the same logic” for production is the most reliable bug generator in this business.
  • ☐ Config out of code: instruments, sizes, thresholds, endpoints in versioned config files; secrets in environment/secret storage, never in the repo (and never in shell history — history | grep -i key on your own machine is a sobering audit).
  • ☐ Pinned, reproducible environment (lockfile, container, or both). “Works on my machine” must be a provable statement.
  • ☐ Idempotent startup: the process can crash and restart at any moment and reconstruct its state from the broker/exchange, not from memory or local files it hopes are current.
  • ☐ Clock discipline: NTP-synced host, all internal timestamps UTC, timezone conversions only at display boundaries. Off-by-one-timezone is the classic silent killer of daily strategies.

Gate 3 — Infrastructure

  • ☐ A boring VPS in a reliable region (or your broker’s supported colocation if latency genuinely matters — for daily/hourly strategies it doesn’t). Residential connections and laptops are for development only.
  • ☐ Process supervision: systemd unit or container with restart policy, memory limits, and logs shipped somewhere the process can’t corrupt.
  • ☐ Independent monitoring host (can be a free-tier cron elsewhere): the machine watching the strategy must not be the machine running it.
  • ☐ Deploy runbook: documented, tested steps to deploy, roll back, and cold-start from nothing. If recovery lives in your head, you don’t have recovery — you have a plan to have a bad week.

Gate 4 — Execution safety (the account-savers)

  • ☐ Kill switch, physically separate: an independent process (ideally a different host) that flattens all positions and cancels all orders when triggered — manually, by heartbeat loss, or by breaching a hard drawdown/exposure line. It must not share code or state with the strategy it polices. This is the single highest-value item on this page.
  • ☐ Order idempotency: client order IDs on every order; on any uncertainty (timeout, disconnect), reconcile before re-sending. Retry loops without reconciliation are how bots buy the same position five times.
  • ☐ Pre-trade limit checks, enforced in code, per order and per day: max order size, max position, max notional, max order rate. Fat fingers happen in config files too.
  • ☐ Partial-fill and reject handling actually tested — by simulating them, not by hoping. Include exchange-halt and symbol-suspension paths.
  • ☐ Rate-limit budgets for every API with backoff; hitting a broker rate limit mid-liquidation is a bad time to learn about 429s.

Gate 5 — Monitoring and reconciliation

  • ☐ Heartbeats with escalation: strategy emits liveness; the independent monitor alerts (phone-level, not email-level) on silence. Silence must be indistinguishable from emergency — a monitor that only reports success reports nothing.
  • ☐ Data-staleness detection: alert when feed timestamps stop advancing. A strategy trading yesterday’s prices believes everything is fine.
  • ☐ Daily reconciliation, automated: your system’s positions/P&L/fees vs. the broker’s statement, every day, diff alerted. This catches execution bugs, fee surprises, and corporate-action mishandling within 24 hours instead of at tax time. Second-highest-value item here.
  • ☐ Decision logging: every signal, order, fill, and skip with inputs attached, retained. When live diverges from backtest — it will — this log is the only way to learn why.
  • ☐ Live-vs-backtest tracking: realized fills vs. modeled fills, realized signal P&L vs. simulated, reviewed weekly. Divergence trend is your earliest decay indicator.

Gate 6 — Go-live protocol

  • ☐ Paper period (2–8 weeks) with the real execution path against live markets; gate on fill-model accuracy, not just P&L sign.
  • ☐ Minimum-size live period: real money, embarrassingly small, long enough to see every order state (partial, reject, cancel, halt) at least once.
  • ☐ Written scale schedule with stop criteria: size steps, the metric gates for each step, and the drawdown/divergence conditions that force a step down. Decide them now, while you’re calm.
  • ☐ Incident log from day one: every anomaly, cause, fix. Three entries about the same component is a redesign signal.
  • ☐ Quarterly kill-switch drill: actually trigger it. An untested kill switch is a decoration.

The meta-rule

Every item above earns its place by the same logic our paper scoring rewards empirical rigor: assume the system is lying to you until an independent mechanism confirms it isn’t. Backtests overfit; processes crash; feeds stall; brokers disagree. Production readiness is the sum of independent checks that catch each lie early.

This checklist says what must be true; the how — the actual minimal VPS/Docker/Postgres stack with working configs — is in From notebook to production. This checklist is general; regulated entities have compliance layers beyond its scope.

Take it with you: download the plain-markdown checklist — drop it into your repo or issue tracker. The newsletter below gets you the weekly research digest and future checklist revisions.