What I learned writing 40,000 lines of trading code

In 2017 I wanted to trade crypto systematically instead of by feel, so I built the thing that could do it. It grew into more than 40,000 lines — a SQL-based trading and analytics engine running trend analysis across Bitcoin, the majors, and the alts, from scratch, live, with real money moving through it.

The line count is a good hook, so I'll use it, and then I'll take it away: 40,000 lines is not impressive. It's just what doing this correctly costs. The interesting part is everything the number hides — and almost none of it is the trading strategy. Trading systems are hard for boring reasons, and the boring reasons turn out to be the entire job. Here's what eight years of that taught me, and why it applies far outside of crypto.

The math was never the hard part

People assume a trading system is hard because the math is exotic. It usually isn't. The math in a trend or technical-analysis strategy is undergraduate-level, and you can read the formulas on a wiki in an afternoon.

What's hard is that every failure mode is expensive and most of them are dull. The strategy is maybe five percent of the work and it's the five percent everyone wants to talk about. The other ninety-five is making sure a decent idea survives contact with real infrastructure. That ninety-five is where the 40,000 lines went, and it's the part worth learning from.

Lesson 1: Your data is lying to you

The single most important assumption I built the whole system around is that the market data is imperfect. It arrives late. It arrives duplicated. It's briefly, confidently wrong. And a naive system will happily act on any of it.

So the first real engineering was defensive: validate every price, de-duplicate, detect and handle gaps, and — most importantly — decide what happens when a number looks wrong. My rule was simple and it never let me down: a bad number should stop the system, not trade it. Halting on suspicious data costs you a missed opportunity. Trading on it costs you money you don't get back. That asymmetry should decide the default, and in most systems it doesn't, which is why they blow up in ways nobody can reconstruct afterward.

Lesson 2: Backtested and real are different animals

Here is the most expensive gap in the entire field, and everyone walks into it at least once: a strategy that looks beautiful against historical data can lose money the moment it's live.

Backtesting is essential — you should never deploy a strategy you haven't validated against history. But a good backtest is a hypothesis, not a promise. The past didn't have your slippage, your fills, your latency, or the specific way the market behaves when you're actually in it. Overfitting is the ever-present enemy: it's trivially easy to build a model that perfectly explains yesterday and knows nothing about tomorrow. The discipline that keeps you honest is refusing to believe a strategy even after it backtests well — treating live results as the only results that count and staying skeptical the whole way. That skepticism is worth more than any indicator.

(The modern, AI-flavored version of this trap is even more seductive, because a model can overfit in ways that are harder to see. The defense is the same: distrust anything that looks too good.)

Lesson 3: The counterparty will misbehave

You do not control the exchange, and the exchange will have a bad day while you have a position open. Rate limits throttle you at the worst possible moment. Clocks drift. Order books go stale in the milliseconds between reading and acting. Fills come back doubled, or partial, or not at all. The venue simply goes down.

None of this is exceptional; it's Tuesday. So the order-handling code assumes misbehavior as the default: respect rate limits before they bite, make retries idempotent so a repeated request can't double a position, and reconcile fills against what you think happened rather than trusting the confirmation. This is the same defensive posture as the data layer, pointed at a different source of chaos. Systems that assume the happy path work fine in testing and fail in production, because production is where the unhappy paths live.

Lesson 4: Be able to ask "why did it do that?" the next morning

This is the one that quietly justified a lot of the architecture. When real money is involved, the question you will inevitably ask is why did the system do that, and you'll be asking it after the fact, calmly, trying to reconstruct a decision made at 3 a.m.

Building the engine around SQL — with prices, indicators, signals, and results all in a schema I could query and audit — meant I could always answer that question. Clever, opaque, in-memory state performs beautifully right up until you need to explain a loss and discover you can't. Auditability isn't a luxury feature in a money system. It's the thing that lets you learn from a bad day instead of just surviving it.

Why any of this transfers

I don't lead with this project on a consulting site because most of my work is crypto. It isn't. I lead with it because it's the clearest proof of a specific competence: owning hard, high-stakes software end to end — the architecture, the data integrity, the failure handling, the unglamorous reliability work that decides whether a system actually functions when nobody's demoing it.

A trading system is, underneath the costume, an integration problem, a data-quality problem, and a real-time-reliability problem. Those are exactly the problems I get hired to solve in ERPs, integrations, and manufacturing — systems where a wrong number is also expensive, just on a slower clock. The difference is that the market gives you feedback immediately and without mercy. It tells you the same day when your data was dirty, your assumptions were wrong, or your happy-path code met an unhappy path. That's a brutal teacher, and it's the best one I've had.

The bottom line

The 40,000 lines were never about a secret strategy. They were about making a decent idea survive dirty data, a lying backtest, a misbehaving counterparty, and the need to explain itself the next morning. That's the actual work — in trading, and in every serious system I've built since. The boring reliability engineering isn't the tax you pay to do the interesting part. It is the interesting part.

Building something where the data fights back and the failure modes cost real money? That's a comfortable place for me. Let's talk →. Related: the integration archetypes nobody names.