> ## Documentation Index
> Fetch the complete documentation index at: https://uncoded.ch/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Why Backtest — The Operator Case

> Backtesting is the cheapest way to learn what doesn't work. The operator case for testing every strategy against history before risking capital.

<Info>
  **Backtesting is the cheapest way to learn what doesn't work.** A 10-second backtest can save you a 3-month live operation that goes nowhere. Operators who skip backtesting end up paying tuition through real losses; operators who backtest first pay tuition through virtual ones.
</Info>

## The single most important reason to backtest

<Warning>
  **The market does not owe you the same regime tomorrow that it gave you yesterday.** Strategies that worked beautifully in 2021 may have failed in 2022. Strategies that worked in 2024 chop may fail in 2026 trend.

  Backtesting on multiple historical regimes shows you which strategies have **regime robustness** — they perform reasonably across different conditions — versus which strategies are **regime-dependent** — they only work in specific market behavior.

  Operators who deploy regime-dependent strategies during regime mismatches lose money. Operators who deploy regime-robust strategies are more likely to weather any specific regime. Backtesting tells you which is which.
</Warning>

## What backtesting tells you

<CardGroup cols={2}>
  <Card title="Total return" icon="percent">
    Cumulative percentage gain or loss over the historical window. The headline number — but never sufficient alone.
  </Card>

  <Card title="Max drawdown" icon="chart-line-down">
    The worst peak-to-trough decline during the window. The single most important risk metric. Caps your worst-case felt experience.
  </Card>

  <Card title="Win rate and average winner/loser ratio" icon="trophy">
    What percentage of trades closed profitably, and how big were winners vs losers. Tells you the trade-distribution shape.
  </Card>

  <Card title="Number of trades" icon="hashtag">
    How many round-trips occurred. Sample size matters — `5` trades over a year is too few; `100+` is solid; `1000+` may indicate overtrading.
  </Card>

  <Card title="Sharpe ratio" icon="chart-mixed">
    Risk-adjusted return. Total return divided by return volatility. `>1` is decent for crypto; `>2` is excellent.
  </Card>

  <Card title="Average trade duration" icon="clock">
    Mean time between entry and exit. Tells you whether the mode operates on the timescale you expect.
  </Card>
</CardGroup>

## What backtesting does NOT tell you

<Warning>
  **Backtesting is necessary but not sufficient.** Several real-world frictions are difficult to model perfectly:

  * **Order book depth at your exact size.** Backtest assumes fills at recorded prices. Real orders walk the book, especially at larger sizes on thinner symbols.
  * **Exchange-specific micro-behavior.** Maker rebates, taker fees on different VIP tiers, partial fills, retry behavior on transient errors.
  * **Operator behavior.** Live trading involves stress, distraction, panic-closes, override decisions. Backtest is a perfectly disciplined operator who never deviates.
  * **Regime persistence.** A strategy that performed well in 2021 has no guarantee of performing in 2026. Past regime ≠ future regime.
  * **Survivorship bias on long-tail symbols.** Backtesting on `BTCUSDT` is fine because Bitcoin survived. Backtesting on a delisted altcoin is not — the engine assumes the symbol stays tradable.
  * **Black swans.** Truly unprecedented events (FTX collapse, banking-system events, regulatory shocks) aren't predictably in the historical sample.

  Treat backtest as **strong evidence** but not proof. Forward-test on small capital before scaling up.
</Warning>

## Backtest before live, always

<AccordionGroup>
  <Accordion title="Before deploying a new mode" icon="seedling">
    Even pre-built modes (BasicMode, FullBullMarket, etc.) should be backtested against your specific symbol and the regime window you expect to operate in.

    "BasicMode is generally good" doesn't mean "BasicMode on `XRPUSDT` for the next 6 months is good." Validate the specific combination.
  </Accordion>

  <Accordion title="Before adding a new symbol" icon="boxes-stacked">
    Adding `SOLUSDT` to your existing BasicMode setup? Backtest BasicMode on `SOLUSDT` against the window you expect. Symbol behavior varies — what works on `BTCUSDT` may not work on `SOLUSDT`.
  </Accordion>

  <Accordion title="Before authoring a custom strategy" icon="wand-magic-sparkles">
    SignalEditor strategies (RSI mean-reversion, EMA-cross, etc.) need both preview-pane validation (fast iteration) and Backtester validation (deeper historical windows).

    The preview is fast. The Backtester is deeper. Use both.
  </Accordion>

  <Accordion title="Before tuning mode parameters" icon="sliders">
    "I want to change BasicMode's sell ladder from `[0.25, 0.5, 1, 2, 3, 4, 5]` to `[0.5, 1, 2, 3, 5, 7, 10]`." Backtest the new configuration on your symbol and regime window before applying live.

    Tuning without backtesting is gambling on the change.
  </Accordion>

  <Accordion title="Before scaling up capital" icon="ruler-combined">
    "I want to go from `$20,000` BasicMode to `$50,000`." Backtest doesn't directly test capital scaling (the strategy logic is capital-agnostic), but it validates that the underlying strategy is sound. If backtest shows poor performance, scaling up amplifies the underperformance.
  </Accordion>
</AccordionGroup>

## The minimum-viable backtest

For any new mode/symbol combination, run at least:

<Steps>
  <Step title="Recent 12-month window">
    The last full year. Captures recent regime characteristics.
  </Step>

  <Step title="A bear-window test">
    Pick a known bear-market window (e.g., 2022). See how the strategy survived bad regimes.
  </Step>

  <Step title="A chop-window test">
    Pick a known sideways window (e.g., mid-2023). See how the strategy performs without trends.
  </Step>

  <Step title="A bull-window test">
    Pick a known up-trending window (e.g., late 2020 or early 2021). See how the strategy captures uptrends.
  </Step>

  <Step title="Note: do not optimize parameters per window">
    The temptation is to tune the strategy until it works on each window. **Don't.** Curve-fitting in this way means your "optimized" strategy is overfit to history. Use the same parameters across all windows; observe how the strategy performs without per-window tuning.
  </Step>
</Steps>

If a strategy works across all four windows, you have evidence of regime robustness. If it fails in 1-2 of them, decide whether you can stomach the regimes it fails in.

## Backtest as a learning tool

Beyond go/no-go validation, backtests teach:

<AccordionGroup>
  <Accordion title="What does normal mode behavior look like?" icon="eye">
    Backtest output shows you the typical trade frequency, hold duration, P\&L distribution. When you go live, you compare actual behavior to backtest expectations. Match = confidence; mismatch = investigate.
  </Accordion>

  <Accordion title="When does the mode struggle?" icon="circle-exclamation">
    Backtest output shows specific bad weeks/months and why. "BasicMode lost `-12%` during week 32 of 2022 due to a sustained downtrend that fully invested the buy ladder."

    Knowing the failure modes helps you spot them in real time.
  </Accordion>

  <Accordion title="What does drawdown actually feel like?" icon="chart-line-down">
    The equity curve shows the shape of drawdowns. A `-15%` max drawdown that resolves in a week is different from a `-15%` drawdown that takes 3 months to recover.

    The shape matters for operator stomach. Sustained slow drawdowns are harder to hold through than sharp-and-recover drawdowns.
  </Accordion>

  <Accordion title="What's the trade-frequency rhythm?" icon="clock">
    `2 trades/day`? `5 trades/week`? `1 trade/month`? Backtest tells you the natural rhythm — useful for setting your own monitoring expectations.
  </Accordion>
</AccordionGroup>

## How seriously to take backtest results

<AccordionGroup>
  <Accordion title="Strong validation criteria" icon="check-double">
    A backtest result you can trust:

    * Multiple windows tested (bear, chop, bull, recent).
    * Same parameters across all windows (no per-window tuning).
    * Realistic fees (`0.075%` Binance with BNB; venue-specific otherwise).
    * Realistic slippage (`0.05%` on majors at moderate size).
    * Sample size > `100` trades for statistical meaning.
    * Drawdown within your tolerance.
    * Equity curve shape acceptable (not "huge gain followed by drawback").

    If all these hold, you have actionable evidence.
  </Accordion>

  <Accordion title="Weak validation — don't trust" icon="ban">
    A backtest result you should NOT trust:

    * Single window tested.
    * Parameters were swept until best result was found (curve-fit).
    * Default fees / no slippage assumed.
    * Sample size `<20` trades.
    * Drawdown beyond your stomach.
    * Equity curve depends on a single anomalous month.

    These results are "the strategy worked in this exact slice of history." That's not the same as "the strategy will work."
  </Accordion>
</AccordionGroup>

## Backtest then forward-test

<Tip>
  **Backtest is necessary; forward-test confirms.** After a strategy validates across multiple historical windows:

  1. Run live on **small capital** (`$1,500–$3,000`) for `2–4` weeks.
  2. Compare live behavior to backtest expectations:
     * Trade frequency similar?
     * Win rate similar?
     * Drawdown character similar?
  3. If live behavior matches backtest, scale up to full capital.
  4. If live behavior diverges from backtest, investigate — usually it means a regime-specific factor not captured in the backtest.

  This four-step ladder (backtest → forward-test → scale → monitor) is how operators graduate strategies to full capital with confidence.
</Tip>

## What's next

<CardGroup cols={2}>
  <Card title="Reading Results" icon="chart-bar" href="/backtesting/reading-results">
    What each backtest metric means and how to interpret it.
  </Card>

  <Card title="Walk-forward" icon="timeline" href="/backtesting/walk-forward">
    The technique that catches curve-fitting before live deployment.
  </Card>

  <Card title="Shadow mode" icon="masks-theater" href="/backtesting/shadow-mode">
    Forward-testing without committing real capital.
  </Card>

  <Card title="Common mistakes" icon="ban" href="/backtesting/common-mistakes">
    The pitfalls that turn good backtests into bad live performance.
  </Card>

  <Card title="Backtester module" icon="flask" href="/modules/backtester">
    The module that runs your backtests.
  </Card>

  <Card title="Risk Overview" icon="shield" href="/risk-management/overview">
    Risk management as the partner discipline to backtesting.
  </Card>
</CardGroup>
