Why testnet first, when you could just go live with small size
Small size limits how much a bug costs. It does not make the bug appear on schedule, and the bugs that matter only show up in situations you cannot arrange on demand.
Vizanix engineering · about the author
- SECTION
- Why and when
- PUBLISHED
- 2026-08-30
- CHAPTERS
- 4
- READ NEXT
- 3
- LANGUAGE
- written in English
The argument for skipping testnet is reasonable on its face. Testnet liquidity is fake, fills are unrealistic, and a small live position tests the real thing. Why not just start at minimum size?
Because the two environments catch different failures, and the ones testnet catches are the expensive ones.
What live-small does not give you
A minimum-size live position tests the happy path: an order goes out, it fills, a stop sits behind it. What it does not test is everything that happens when something goes wrong — because you cannot make those things happen on demand with real money.
- A rejected order, for each rejection reason.
- A partial fill, and whether the remainder is cancelled correctly.
- A reconnect mid-position, and whether reconciliation runs before trading resumes.
- A position that already exists when the bot starts.
- Hitting a rate limit and backing off correctly.
- An order that times out with unknown status.
Each of these is a code path that will eventually execute in production. On testnet you can trigger them deliberately. Live, you wait for them, and the first time is during an incident.
The drills that matter
Testnet is where we run failure injection, and it is the part of delivery clients find surprising:
- Kill the WebSocket mid-position. Does the bot reconcile before it trades again? Does it produce a duplicate order?
- Restart the process with an open position. Does it re-derive state from the exchange or trust a local file?
- Force a partial fill. Is the remainder cancelled, and is the bracket sized from the filled quantity?
- Submit an order that violates a filter. Is the rejection classified correctly, or blindly retried?
- Fire the kill switch. Does everything actually go flat, and how long does it take?
Where testnet is genuinely weak
It is worth being clear about what testnet does not prove, because vendors sometimes oversell it:
- Fill realism. Testnet books are thin and artificial. Nothing about your slippage assumption is validated here.
- Latency. Testnet infrastructure is not production infrastructure.
- Market behaviour. Prices there are not real prices.
- Strategy performance. Testnet P&L means nothing at all.
That is why testnet is one stage, not the whole process. It validates the machinery; paper trading against the live book validates the fill assumptions; only then does live with minimum size make sense.
The sequence, and why it is cheap
| Stage | Validates | Cost of a bug here |
|---|---|---|
| Backtest | Whether the hypothesis has historical support | Compute |
| Testnet | Order lifecycle, error handling, recovery | Nothing |
| Paper | Fill assumptions, latency, live data handling | Nothing |
| Live minimum | Everything together, with real money | Small |
| Live scaled | Capacity | Real |
Each stage moves discovery earlier, where it is cheaper. Skipping testnet does not remove that work — it relocates it to the stage where a mistake has a price.
This article describes engineering practice. It is not investment advice. Vizanix develops software and does not promise trading returns.