40,000 lines, real money, since 2017
A SQL-based trading and analytics engine built from scratch in 2017 — and the AI-driven, prediction-market work it turned into.
SQL Server · market data pipelines · exchange APIs · technical indicators · backtesting

The strategies stay private, for reasons that should be obvious. The engineering is worth talking about.
The premise
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 of code — a SQL-based trading and analytics engine that ran trend analysis across Bitcoin, the majors, and the alts, from scratch, live, with real money moving through it.
I lead with the line count because it's a good hook, but it's the least interesting fact about the project. Forty thousand lines is just what it costs to do this correctly. The interesting part is everything the number is hiding: the data integrity work, the failure handling, the slow accumulation of respect for how hostile markets are to a clever idea that hasn't met reality yet.
This case study is about that — the engineering of a system with real money at stake — and about where the work went next, which is AI-driven strategy and prediction markets. What it deliberately doesn't include is how any of it actually trades. That part isn't for a website.
The problem, stated honestly
People assume trading systems are hard because the math is hard. It usually isn't. The math in a trend or technical-analysis strategy is undergraduate-level. What makes these systems hard is that every failure mode is expensive and most of them are boring.
The market data you depend on arrives late, or duplicated, or briefly wrong, and your strategy will happily act on garbage if you let it. Exchange APIs rate-limit you at the worst possible moment. Clocks drift. Order books go stale between the instant you read them and the instant you act. Fills come back doubled, or not at all, or half. An exchange simply goes down while you have a position open. None of these are in the tutorial, and every one of them can quietly turn a strategy that looked profitable on paper into one that loses money in practice.
So the actual problem was never "find a good strategy." It was "build a system trustworthy enough that a good strategy survives contact with real infrastructure." That's an engineering problem, and it's the one I spent the 40,000 lines on.
The approach
The system was built around SQL as the backbone — which, in 2017 and honestly still today, was the right pragmatic call for a data-heavy analytics-and-trading engine one person needed to own end to end. Price history, indicators, signals, and results all lived in a schema I could query, audit, and reason about, rather than scattered across opaque in-memory state I couldn't inspect after the fact. When real money is involved, being able to answer "why did it do that?" the next morning is not a luxury.
On top of that sat the pieces you'd expect, each one earned by a problem:
- A market-data layer built to assume the feed is imperfect — validating, de-duplicating, and gap-filling before anything downstream trusted a price. The rule was simple: a bad number should stop the system, not trade it.
- A technical-indicator and trend-analysis engine across BTC, the majors, and the alts — the part that turned raw prices into something a strategy could reason about.
- A backtesting capability, because the single most important discipline in this work is refusing to believe a strategy until it's been validated against history — and then staying skeptical even after, because backtested and real are different animals and the gap between them is where accounts go to die.
- Exchange integration and order handling built around the assumption that the exchange will misbehave — rate limits respected, retries idempotent, fills reconciled rather than trusted.
The through-line was defensive design. I built the system expecting its inputs and its counterparties to fail, because in this domain they do, and the systems that don't plan for it are the ones that blow up.
Where it went: AI and prediction markets
The 2017 engine is where the fluency came from. The work since has moved in two directions, both of which I'm keeping conceptual here.
The first is AI-driven strategy — applying modern models and agentic approaches to markets, with all the skepticism the backtesting years taught me. AI doesn't repeal the hard parts. If anything it adds a seductive new way to overfit, and the discipline that keeps you honest is the same one it always was: validate ruthlessly, distrust anything that looks too good, and respect the difference between a chart and a fill.
The second is prediction markets. I've gotten into Polymarket and prediction-market analysis — a different shape of the same underlying interest, which is finding signal in messy, fast-moving, real-money data and building the tooling to act on it. Related work includes signal detection over on-chain activity — tracing the coordinated behavior that shows up before a move — which is the same instinct pointed at a different data source.
I keep the specifics of all of this close, and I'd encourage anyone in this space to do the same. What I'll say publicly is the premise: I've spent the better part of a decade building software where the data is adversarial, the stakes are real, and being wrong is measured in dollars. That's a rare kind of training, and it transfers to any system where correctness under pressure actually matters.
Why this belongs on a consulting site
Most of my consulting work is not about crypto. It's about ERPs, integrations, manufacturing, and AI. So why lead with a trading engine?
Because it's the clearest proof that I can own hard, high-stakes software end to end — architecture, data integrity, failure handling, the unglamorous reliability work that determines whether a system actually functions when it's not being demoed. A trading system is an integration problem, a data-quality problem, and a real-time-reliability problem wearing a more exciting costume. Those are exactly the problems I get hired to solve everywhere else. This is just the version with the most honest feedback loop, because the market tells you immediately and without mercy when you got it wrong.
Tech stack
SQL Server as the analytical and operational backbone; custom market-data pipelines with validation and gap-filling; a technical-indicator and trend-analysis engine; a backtesting capability; exchange API integration with rate-limit-aware, idempotent order handling. The modern work adds AI/agentic strategy and prediction-market data on top — described here in premise only.
Building something where the data fights back and the failure modes cost real money? That's a comfortable place for me. Let's talk →
Next case study: A cheese factory, a WMS, and an ERP that refused to talk to it →
got a system like this? — one email starts it