The problemEight teams, twenty-six games, one person keeping score
A Wednesday cash game is a small tournament. Eight teams, pool play, a bracket, a back draw and a final: twenty-six games in about three hours, and somebody has to keep all of it straight while also playing. The first night ran on a paper scoresheet. The next three ran through a chat thread, with an image model drawing the results graphic, and it got the numbers wrong five times in three weeks.
A cash game lives on the numbers being right. Standings nobody trusts are worse than no standings, and a results post that has to be corrected the next morning is the kind of thing that ends a game.
What I builtA night that runs from the phones on the court
Moneybag is three things. The engine owns every number: it takes a score and gives back standings, seeds and a bracket, and it refuses to guess when a result doesn't fit. The phones are how the night runs: I open it from mine, each player reports their own score from theirs, and every phone has it in seconds. The site is where it lands: the night page, the career leaderboard, a page for every player, and the lab, which rates everyone from every game they've played.
Code owns the numbers. Nobody posts a number it can't prove.
How it worksThree beats
- Open. From my phone: the date, the teams, the courts. It checks every name against last week's partners and builds the schedule before anyone's at the club.
- Play. The phones go live. Whoever finishes reports the score, two taps, and nothing sends until they've read it back. When pool play's done, one tap seeds the bracket, and the bracket plays out live on every phone.
- Close. One tap. The ledger is archived, the three graphics render, and the site publishes: that night's page, the leaderboard, every player's page and the lab, all at once, every number traced to the ledger.
What it replacedA chat thread, an image model, and a paper scoresheet
Before the engine, the night ran through a chat thread and the results graphic came from an image model, which is how the numbers went wrong five times in three weeks. Now every graphic is drawn from the ledger, the leaderboard is right the moment the night closes, and the whole season is on film: every match, court by court. The lab is the part I didn't plan. Once every game was in one ledger, a rating fell out of it, and the rating turned out to be worth a section of its own.
The Moneybag RatingA rating that grades itself
Before a game starts on a Wednesday, the app puts a call on it. Kendall and Lucas over Ben and Kade, 15-3, 97%. They won 15-4.
The number behind that call is simple. Every game is a margin: win 15-9 and your side is plus six. Your rating is how many points a pair of you would beat an average Moneybag pair by, in a game to 15. The engine finds the ratings that fit every game anyone's ever played, all at once, and it uses how wrong it's been so far to decide how sure to be.
That last part matters more than the formula. Every call is locked before the night starts, and after the night, that night's page grades every one of them, upsets first.
78%166 of 214 pre-game calls had the winner.Every call since July, graded on the night page it was made for.
And it's been getting better as the games pile up. Through early September the favorite won about two of every three. Since then it's more than four of every five. To be fair to the formula, most of that is more data: a plain win-rate guess got better over the same weeks too. The rating stays a little ahead of it. When it calls a game a coin flip, believe it. That's the one place it has no edge. One footnote: the formula was settled in early September, after a look at the summer's games. That could only flatter the summer calls, and they're still the weaker ones.
Getting sharper
Every pre-game call since July, night by night. The top line is the record so far; the dots are the calls, one per game, the surer ones higher.
Tap a night for its count, or a dot for the game behind it.
the favorite won it didn't right so far, with its 95% band a plain win-rate guess
Under each night: how many calls it had, and the games already behind each player's number (the median).
It isn't DUPR, and it isn't trying to be. DUPR rates a million players across every club and tournament, and a 4.2 means something anywhere. This one rates the fifty-one people who play each other on Wednesdays, and it means nothing anywhere else. That's the trade. Inside the group it's sharper, because it sees every game, every partner swap and every point. Outside it, use DUPR.
On the recordThe facts, same six for every one I build
- The problem
- Eight teams and twenty-six games a night, kept by one person who was also playing, with the results graphic drawn by an image model that got the numbers wrong five times in three weeks.
- What we built
- An engine that owns every number, the phones the night runs on, and the site it lands on: night pages, a career leaderboard, a page for every player, the lab and its rating.
- How long
- Five weeks from the first night on paper to the engine's first night, June 16 to July 22, 2026. The phones and the site were built in one night, August 18, and ran in shadow that Wednesday.
- Running since
- July 22, 2026 on the engine. The phones and the site since August 19; the night has opened from my phone since September 30. Public at moneybagpickle.vercel.app.
- By the numbers
- 18 nights, 51 players, 464 games, June 16 to October 21, 2026, as the site's own leaderboard counts them.
- What it replaced
- A chat thread, an image model's graphics, and a paper scoresheet.
- Built for
- My own Wednesday game at Meridian Club in Boise. The game is invite only; the site is public.
- Made of
- A Python engine with no dependencies and a ledger of JSON files; a Next.js site on Vercel; Supabase under the live night; and one small always-on machine on Fly that runs the night once I open it from my phone. Every graphic is drawn from the ledger, never by an image model.