Reliability over strategy

A client arrived with an unusual brief: "I don't want dozens of trades. The system should enter rarely, hold for a long time, and carry risk closer to an investment portfolio."

It sounds simpler than an aggressive bot. In practice it is harder.

Why trading rarely is harder than trading often

A hundred trades a month and one mistake disappears into the statistics. Five trades and a single bad order costs the month.

The list of things that can go wrong does not get shorter:

• an order never reached the exchange;
• a reconnect opened the position twice;
• the websocket hung;
• the container restarted and the strategy resumed trading although it had been stopped by hand.

At a hundred trades these smear across the distribution. At five, each one is the month's result.

Most of the code is not about trading

It is about trading not breaking.

• The websocket reconnects on its own and verifies that no data was missed, rather than simply that the socket is open again.
• The circuit breaker lives outside the process and survives a container restart. Otherwise a crash silently re-enables a system that was deliberately stopped.
• Emergency close works from a phone — every position, in a couple of actions.
• Money is never a float, only exact types. Rounding in money arithmetic is not acceptable.

The important part happened before the bot ran

Before it reached real money, the strategy went through historical data, a check for missing quotes, walk-forward optimisation and a broker simulator.

The order mattered: first we tried to break the system deliberately, and only then gave it access to a live market.

That is a habit from QA. For twelve years I broke other people's code in a bank, a vehicle-history product and a marketplace, and you quickly learn to ask not "does the happy path work" but "what happens when it doesn't". For a system that runs around the clock and moves real money, that is not an idle question.

What counts as delivery

We handed over the code two months before the project closed. Throughout that time we stayed available: watching how the system behaved on a live market, working through unusual situations, making changes. No halts, no breach of the risk limits.

The project closed on the day the client said he could take it from here.

Proper delivery is not code that works on the developer's machine. It is code you can stop watching and still be confident it keeps working.