Building Sherwood

I called it Sherwood — a nod to Robin Hood: partly the idea, and partly Robinhood, the trading platform I was going to use first.

I’d gotten interested in finance as a side project — specifically high-frequency trading, and trading on the edges of the market, like crypto. I tend to learn things by building them, so Sherwood became my way in: a self-hosted trading platform that watches the S&P 500 and crypto across a few timeframes, runs strategies against live and historical data, and paper-trades the results. It runs in a Docker container on a box in my closet, for just the cost of the electricity.

It came together quickly. In about a month, Sherwood went from an empty repo to ~17,000 lines of Go — a REST API, five strategies, a backtester, a paper-trading loop, real-time updates, 49 tests, CI. I’d describe a feature and it would show up, usually faster than I expected. I’d never built anything at that pace.

After a while, though, I started to notice what that pace was costing me.

The first sign was small: I went to extend a part of the system and had to stop and re-learn how it worked. The agent had built it a few sessions back, and even though I’d reviewed it, code you’ve reviewed doesn’t lodge in your head the way code you’ve written does. I knew the system — I just no longer carried all of it in my head.

The sessions got slower, too. Each one started with me re-explaining the same context: the conventions we’d settled on, last week’s decision about how orders were stored, a bug we’d already fixed once or twice. The agent was sharp within a session and forgetful between them, so I spent the first part of each session bringing it back up to speed.

The bigger issue was drift. It wasn’t that I didn’t understand the system — I did. It was that I couldn’t thoroughly review every change, and at that pace there were a lot of them. Small deviations slipped through: a convention bent one way, an abstraction that didn’t quite fit. Each looked harmless on its own. They compounded, and I usually didn’t catch a given drift until it had spread far enough that fixing it meant a long refactor instead of a quick change.

None of this sank the project. But it shifted the question I was asking: from how much can I build? to how do I build this fast and still catch the drift before it compounds?