Building a Prediction Market From Scratch (0): Why, and Why Every Line Will Be Open

Last weekend I didn’t make any other plans. I just wanted to settle a question that had been sitting in the back of my head for a long time: with one person, could you actually build a whole prediction-market backend — not a demo, but the kind you’d dare to put in front of real money?

Matching, clearing, risk, reconciliation — I’ve worked on these for years, and they’ve pulled me out of bed in the middle of the night more times than I’d like to count. I know where the soft spots are. So this wasn’t an idle “wouldn’t it be cool.” It was more like an itch I finally decided to scratch.

Two days later, it was running. That’s where this series comes from. Over the coming chapters I’ll build the whole thing again, out in the open, one module at a time — and I won’t skip the parts that are actually hard.

First, the thing I care about most

Before anything else, let me say the part that actually matters to me.

Every line of code in this series will be open. Every design decision — including the ones I got wrong and had to walk back — gets written down. All of it free, no strings: no “the core is open, the good parts cost money,” no license that quietly forbids you from shipping a product with it, no interesting 20% locked behind a wall. If you want to take the whole thing and build a business on it, take it. You don’t owe me anything.

I’m doing it this way because most of what goes into a trading system was never really a secret. How to model an account so money can’t appear out of thin air or quietly leak away; how to make matching reproducible; where the seams are that quietly kill a system in production — this knowledge mostly just sits scattered around, half-written-down, locked inside a few people’s heads and private repos. I’d rather put one complete, working, honest version somewhere anyone can read it. That feels more useful than keeping it.

One person, and why that’s actually enough now

A few years back, a thing like this was a team and the better part of a year. A couple of people on the frontend, a couple on the backend, the most senior person pulled aside to wrestle with matching alone, someone permanently babysitting the database. I sat in plenty of those rooms. Half the calendar went to meetings whose only purpose was to keep everyone’s mental model of the same interface from drifting apart.

What changed isn’t that “AI can write code” — everyone knows that by now. What changed, for me, is quieter and a little counterintuitive. All the work that used to be spread across people and is tedious and error-prone by hand — scaffolding, boilerplate, migrations, half the tests, most of the docs — I hand to the AI now. It’s steadier than an intern and I never have to explain the same thing twice. So the attention I used to spend herding people, I now spend on the parts that decide whether the thing lives or dies.

And here’s the part that surprised me the first time I noticed it: when every core detail lives in one head, the system tends to break less, not more.

Trading systems rarely die because someone fat-fingered a function. They die at the seams. The matching person assumes clearing will mop up the remainder; the clearing person assumes matching already checked the balance; risk has its own private theory about the order money moves in. Each piece is correct on its own. You bolt them together, let real money flow through, and it cracks right at the joint. I’ve watched this happen more than once, and when you trace it all the way down, the root cause is almost always the same sentence: everyone assumed someone else had it.

One person, plus an AI that doesn’t get tired or forget, owns the whole thing end to end — and those seams just aren’t there to crack. The price is that this one person has to genuinely understand every block. Which, honestly, is the part I enjoy.

The places I won’t let myself wave a hand

There’s a wide river between a trading system that demos and one you’d dare to take live. To demo, you wire the pieces together, run the happy path, done. To go live, you have to answer a string of questions that keep you up at night. I’ve fallen into each of these myself, and I’ve been the one pulling other people out of them. Let me lay them on the table, because the whole series is really just walking down this list:

The account model. How is money kept? How do you separate available balance from frozen? You freeze on order, unfreeze on cancel, settle on fill — and across all that motion, can you swear that not one cent ever appears from nowhere or quietly goes missing? This is the foundation. Tilt it a millimeter and every floor above cracks.

Matching and clearing. Who trades with whom, at what price, and afterward how does each side’s balance and position move? Where does the unfilled half of a limit order go; what happens to the part of a market order nobody fills? Simple on paper, pure devil-in-the-details in code.

Risk control. Do you lock funds before you accept an order, and how much? How do you stop someone trading with themselves? An order that’s obviously wrong — does the system reject it on the spot, or let it in and wait for the blowup?

Fund safety. Deposits and withdrawals sit closest to the money, which means they’re the part everyone with bad intentions is watching. One sloppy signing authorization, one withdrawal whose upper bound you forgot to pin down, and you’ve handed money to someone who should never have touched it. I’ll give this a whole chapter, and use it to show how Polymarket pulls the same thing off non-custodially, on-chain.

The edge cases. A service dies, a message goes missing, the database lags half a beat — does the system get the books wrong because of it? This is the hardest line between a toy and a product. Anyone can write the happy path. The craft is all in the error branches.

The prediction market we’re building is, honestly, simpler than something like a leveraged perpetuals exchange — no liquidations, no funding rates, balances and positions all stay non-negative. But not one item on that list gets to be skipped. Simple doesn’t buy you the right to be sloppy.

Three things I’ll keep next to me the whole way

Talk only about your own code for long enough and it turns into a hall of mirrors. So I’ll keep three things next to me throughout, to mark where “it runs” and “it’s production-grade” actually part ways.

The first is the project itself — three Rust services you can run, change, and ship. That’s the spine of the series.

The second is an article I think highly of. The author is also one person plus an AI, chewing through a perpetuals DEX, and at one point he takes the deposit/withdrawal module completely apart. His way of thinking and what I’m trying to get across are nearly the same thing, so I’ll borrow his reasoning when it fits.

The third is Polymarket — the largest prediction market in the world, real money, running on-chain.

Here’s what I find genuinely nice: under the hood, all three are the same shape — match off-chain, settle in one central place. Polymarket matches off-chain on an order book and settles on-chain through contracts; that perpetuals DEX does off-chain matching, on-chain settlement; ours does off-chain matching, database settlement. Understand one and the other two click into place. I’ll lean on this again and again, especially once we get to the money.

A word about working with the AI

This series is itself the product of one person and an AI. If you want to work this way too, there are three habits I keep — not rules, just things I’ve learned the hard way.

I write the spec before the code. I get clear on what I’m building, where the edges are, and what counts as done — on paper — and only then let the AI implement it. Every minute I skip here comes back later as debugging, with interest. There’s a folder of these specs in the repo; you’ll see them.

I make myself explain the principle out loud. The AI will hand me working code all day, but whether I can say why it’s correct is on me. The spots I can’t explain are exactly the spots I don’t really understand yet — and those are the spots that come back to bite.

And I verify in small steps. Finish a block, run it, look at the real output, then move on. In a trading system, “I assumed it worked” is the single most expensive sentence there is.

That’s enough preamble. Next chapter, we get the system running on your machine and place a first order by hand. And the code — every line of it — will be sitting in the open repo, free, no strings, exactly like I said.