Start here
This is Tourney — a March Madness pool where you draft individual college basketball players and coaches, not just teams, and your score updates automatically as real games happen. (New to the pool? Read the instructions — how to join, pay, and how scoring works.) It's built end to end, top to bottom: the product, the live-scoring engine, two different AI integrations, and the security model underneath all of it. This page is the fast tour. Everything on it is real and running — click through and try it. Coming soon: Runway — an agentic AI tool that asks you questions to help figure out if you can retire.
This started as a way to actually dive deep into AI — hands-on enough to work toward Anthropic's Claude certification, not another toy project. The idea was simple: take the pool I've run for 15+ years and upgrade the greatest pool ever into a real, live application.
A normal bracket pool asks you to predict which teams win. This one asks you to draft individual players — 22 of them, across five groups, seeded 1–4 through 13–16 plus head coaches — and your score comes from what those specific people actually do in real games. Two people who agree on every game winner can still land on completely different scores, because they drafted different players off the same teams. It rewards knowing the players, not just the bracket.
The pool itself has run for 15+ years, on paper, then spreadsheets, then a semi-automated Google Sheet. This year it became this. The full origin story is worth the five minutes if you want the "why" before the "how."
Nothing below is a mockup or a demo environment. It's the live app — mid-tournament right now, with games played through the Sweet 16.
None of this started as expertise. It became expertise by getting built.
Every layer here is something learned to make this real: a Flask web app backed by MySQL, containerized with Docker and served through Nginx; a frontend that updates itself live via HTMX instead of full page reloads; a background scheduler that talks to ESPN's live APIs; the Model Context Protocol wired up so an AI client and an AI server can hand tool calls back and forth safely; email delivery through AWS SES; a second DuckDB warehouse, rebuilt from the live database, for analysis that never touches production; a real CI/CD pipeline that won't let a change reach production without passing tests first. None of it existed a year ago. All of it runs today, for real people, during a live tournament.
It isn't a one-off build, either — there's an actual process behind it: specs before code, an independent review pass before anything ships, a deploy pipeline that gates on tests, not vibes. The Process page → shows how that loop actually runs.
Two different AI setups, running side by side, generating the same daily commentary — a genuine build-vs-buy comparison, not a gimmick.
Read the full AI page → — it includes the actual tool-call sequence diagram and the security constraints the AI worker runs under. Or try it live from the CTAs above.
A side project that handles real names, emails, and phone numbers doesn't get to skip security because it's small.
Full security page → covers the rest: session handling, CSRF, rate limiting, and secret rotation.
This isn't a static bracket you fill in once and forget. It's a running system.
See it end to end on the Big Picture page — that's where the actual data-flow diagram lives.
This page is the trailer. Everything under /about is the full picture.