Six mistakes almost every first trading bot makes

We are frequently the second developer on a system. The defects cluster, and the same six account for most of what we find.

1. Costs applied after the fact

The backtest computes P&L and subtracts fees at the end. That is not the same as applying them inside the decision, because costs change which trades happen at all. A strategy with an average edge below its round-trip cost should never have taken those trades — and once they are removed, the remaining strategy is a different, much smaller thing.

Fix: cost goes in the entry filter, not in the report. See the break-even calculator for the one-line version.

2. Trusting local state

The bot keeps its position in memory, or in a JSON file, and treats that as truth. Then it restarts, or the WebSocket drops, and the exchange knows something the bot does not.

Fix: the exchange is the source of truth. Local state is a cache that can be wrong. Reconcile on every reconnect and every start, before trading resumes — see the order state machine.

3. Sizing from the balance instead of the stop

“Use 5% of the account” gives you wildly different risk depending on where the stop sits. The same 5% is a small risk with a 0.5% stop and an enormous one with a 10% stop, and the strategy has no idea which it just took.

Fix: risk in currency divided by distance to the stop. Constant risk across instruments and volatility regimes. See position sizing.

4. No kill switch, or one that has never been fired

Ask of any bot: if it started behaving wrongly right now, how long until the account is flat? If the answer involves SSH, reading code, or cancelling orders by hand in the exchange UI, that duration is your real risk exposure.

Fix: one command that cancels everything and flattens, at the highest request priority, reachable from the control plane, idempotent, and tested on testnet before going live.

5. Silent failure

The most dangerous state is a bot that appears to be running and is not trading. The process is up, the logs show nothing alarming, and the WebSocket died forty minutes ago.

Fix: measure liveness on inbound data, not on process state. Emit a positive heartbeat and alarm on its absence. Log the negatives — why a signal did not fire — so “doing nothing” is distinguishable from “broken”. See monitoring.

6. Building the platform before the bot

The most expensive mistake and the least technical. Six weeks into a project there is a plugin architecture, a strategy DSL, a multi-exchange abstraction and a dashboard — and nothing has ever placed an order.

Fix: one strategy, one market, running on testnet, in week one. Generalise afterwards, against a real thing that works. Every abstraction built before there is a working case is a guess about requirements you do not have yet.

The pattern underneath

Five of the six are the same error in different clothing: optimism about the cases you did not test. The happy path is easy and gets all the attention. The failure paths are where the money is, and they are boring to write.