Beware the Ides of Paper

Paper trading has a reputation as the boring bit. You have built the thing; now you watch it pretend. In practice it was where the project stopped being a modelling exercise and started being engineering.

The first decision I would defend to anyone: make the paper broker pessimistic on purpose.

Our simulated fills cross the spread the wrong way every time - buys fill at the ask, sells at the bid - and then take a further 0.05% of premium as market impact. A paper book that fills at the mid-price is a machine for generating encouraging graphs, and encouraging graphs are exactly what you do not want before committing money. If the strategy only works when you get the mid, it does not work.

The leg that leaves you naked

Then the real tape taught its first lesson.

Every position this system takes is a spread - two or four legs, structured so the maximum loss is known before entry. That guarantee holds only if all the legs actually exist. And orders do not fill simultaneously.

Consider: you sell the short leg. It fills. You buy the protective long leg. It does not fill - thin book, a tick moved, whatever. For those seconds or minutes you are holding a naked short option. Your defined-risk position, the one whose maximum loss you carefully computed, now has an unbounded one.

Two fixes, both structural rather than clever:

1. Ordering. Protective longs go on first, then the shorts. A pending short is always covered. This inverts the intuitive order - you would rather collect the premium first - and it is the single most important line in the execution layer.
2. Timeout and unwind. If leg two has not filled within fifteen seconds, force it at immediate-or-cancel. If that fails, unwind leg one at market and abort. Log it. Never sit on a half-built spread hoping.

There is a comment in that module that still reads: never leaves a naked leg. It has been tested more than any other assertion in the codebase.

Moving out of the laptop

By late June the system was working and the laptop was the problem. A trading loop that stops when the lid closes is not a trading loop; it is a demo.

So the whole operation moved to a small EC2 box in Mumbai - close to the exchange, always awake. systemd timers start each book in the morning; the loops run on their own cadence; a cron job writes the end-of-day report at 15:45 and pushes it to Telegram. I can be asleep, on a train, or usefully employed elsewhere, and the machine keeps its appointments.

This is the least glamorous phase and easily half the total work. Token refresh. Holiday calendars - the NSE closes on days no generic library knows about, and expiry rolls backward when it lands on one. Reconnect logic for a websocket that drops. A rate limiter and an audit log so that every single call to the broker's API is recorded with its outcome, which is how I can tell you that on a recent Wednesday the system made 986 API calls and every one returned ok.

The honest bit

That box is a t3.micro. It has 936MB of memory. It swaps when four trading loops and the dashboard run at once, and it has been on the to-do list under #76 for weeks, along with a pending libc6 upgrade that needs a reboot I keep declining to schedule during market hours.

It is entirely typical of real systems: the thing works, is monitored, is not yet tidy, and the untidiness is tracked rather than forgotten. I mention it because write-ups of AI-built systems tend to stop at the demo. The demo was June. The three months since have been operations.

What this means for senior product and engineering leadership

The distance between works and works unattended, every weekday, without me is where nearly all the engineering lives - and it is almost entirely composed of things no specification mentions. Fill ordering. Timeouts. Holiday calendars. Token expiry. Memory pressure.

An AI agent will happily build you the demo in an afternoon. Budget for the ninety days that follow, because that is the part that decides whether you have a system or a screenshot.