I write specs for a living. Claude Code built my NBA forecast

Originally published at clutchledger.com/story.

I'm a senior business analyst and an AI product owner. At work I decide what a product should do and write it down so that developers can build it. This autumn I did that for myself: an NBA forecast called Clutch, with Claude Code as my developer. I don't write the code. This post is about how that works, what rules I set, and what the honest result looks like.

What it does, in one paragraph
Every night of the NBA season, Clutch puts one number on every game: the chance that the home team wins. Before the game tips, that number is written to a public Git repository, hashed and chained to the file before it, so I can't quietly change it later. After the final, it is graded in public, on the same games as ESPN's BPI, the market's final price and the simplest rule there is: pick the home team.

How an analyst and Claude Code build it
There is no server. Python jobs run on a schedule on GitHub Actions. They fetch the night's games, the injury report and the market's prices, write the numbers into a Postgres database (Supabase) and seal them. The iPhone app and the web app are one Expo codebase that reads those rows. The game simulation and the What-If lab run on the device.

My part is the same as at work: I decide what Clutch should do, write down what counts as right, check every change in the simulator and the browser, and say yes or no. Claude Code writes the code and the tests. Since September 1 there have been more than 1,400 commits across the project's four repositories, and about 95 in 100 of them name Claude as co-author. More than 5,400 automated tests run before anything ships.

What I'd tell another analyst
If you write specs for a living and want to build your own product this way:

Write it like an analysis. Before anything is built, write down what counts as right: the acceptance criteria, the limits, the words that must never appear. Claude writes the code; what to build is yours. For Clutch, one of those rules is that you can never put money on a game in it, and a test fails the build if a single word from that world shows up in the app's text.
"Done" isn't enough. Ask for proof. For every change: the tests, a preview, a screenshot. Don't accept anything you haven't looked at yourself.
Guard rails first. Keep production writes, releases and builds in your own hands. Claude can't write to the production database, deploy a server function or start an App Store build. For those it hands me one script that checks itself first (dry run, apply, re-test), and I run it.
Measure honestly. Decide the comparison before you see the result, and publish whatever comes out. For Clutch that meant writing on the page that my model didn't beat the market, and keeping every graded game as it was graded.
Sealed before tip, and how to check it
Each time a number changes, a scheduled job writes the night's numbers to a file in github.com/uguraltunbas/clutch-receipts. Every file carries the SHA-256 hash of the file before it, so the files form a chain. A few numbers are only for paying readers before tip; those go in as a hash of the numbers plus a random salt, and the numbers and the salt are published after the final.

You don't have to trust me. Clone the repo and run this in its folder (Python 3, no packages)

Try it
app.clutchledger.com: tonight's games; make your own call on one, no account needed. It locks at tip and is graded after the final.
The Ledger: every graded game, with ESPN's BPI, the market and the home team beside Clutch.
Open data: the sealed numbers as plain JSON and CSV files.
I wrote this post with Claude's help, the same way I built the app.