As most of you know, I'm an avid poker player. I played card games growing up, picked up poker in my early 20s, and started playing more seriously right around the Moneymaker boom in 2003. I'm someone who likes to keep records, so naturally I've been tracking my sessions since the beginning, about 525 of them across more than two decades, all in a spreadsheet. There are plenty of poker tracking apps out there, but none that I liked enough to migrate two decades of records into. So I kept doing it my way: jotting sessions into my phone's notes app, then transferring them home to the spreadsheet.
I’ve wanted to build my own version for years. I had a clear vision in my head of how it should look and feel. But every time I sat down to start, I hit the same wall. I'm a backend engineer by trade, so the frontend was always the hard part, and the project never made it past my head.
AI has obviously advanced enormously over the last 2-3 years, but the real inflection point came this past December. With Claude Opus 4.5 and OpenAI's GPT-5.1-Codex-Max landing in late November, followed by GPT-5.2 and its Codex variant in mid-December, AI-assisted coding crossed a clear line over the winter holidays. So around early March, I took the opportunity to finally try building this poker app.
From Empty Repo to Working MVP in About Three Hours
I first spent an hour or so in Claude talking through my product idea and vision for this poker tracking app. Not coding: discussing user flows, the data model, the result formula (cash_out − buy_in + food + tips − time_charge), what a "session" actually is, what should be persisted versus derived. Claude pushed back where my schema didn't hold up. By the end of that hour I had a SPEC.md file with the full product specification: tech stack, schema, phased build plan, deployment flow.
I fired up Claude Code in my terminal that same evening and had it reference SPEC.md to scaffold the project. Claude recommended Next.js (App Router, TypeScript, Tailwind CSS) with Supabase for Postgres + auth and Vercel for hosting. Within about an hour, I had a Next.js project scaffolded, a Supabase project provisioned, Google OAuth wired up, and a deployed URL with working authentication. Two hours in, and I already had something live.
The next day, I asked Claude to implement Phase 2 from SPEC.md, the core session tracking flow. It returned a nine-step build plan covering types, theme, layout, primitives, start/live/end session flows, history, and edit/delete. Then it executed all nine steps in about ten minutes. I tested locally, flagged some clipping issues and style drift from the mock, and Claude fixed them. After roughly an hour of work and three hours total overall, I had a functional MVP. Wow.
That working version went with me to a Gametime offsite in Arizona the following week, where I used it to track a couple of real cash game sessions I played. A project I'd been carrying around for a decade went from idea to in-pocket in a weekend. My 20-year spreadsheet officially retired.
How I Worked With Claude Code
I wanted to go deep on this project, not just ship the app but actually understand how capable these models have gotten. The way to learn that, for me, was to stay close to every decision: read the schema proposals, review the PRs, push back when something didn't feel right. I wanted to see how Claude reasoned through its choices at every step (during planning, while coding, when responding to feedback), and that feedback loop was really what I was after. So rather than going hands-off with something like the Ralph Wiggum loop, I took an iterative approach, planning and building feature by feature, the way you'd typically build any product.
That's not the only way to use these tools. There are great frameworks emerging that formalize a plan → build → test → iterate loop with the agent doing more of the execution. Superpowers, GSD, and compound engineering are all worth looking at. The hand-rolled version I ended up with covers the same ground:
SPEC.mdas the source of truth for what to build and why. Iterated heavily upfront, updated whenever the product evolved.CLAUDE.mdfor project conventions, architecture decisions, and patterns I wanted enforced. I told Claude to update both docs whenever it opened a PR that changed them.Small PRs per milestone or feature. I'd describe the change, Claude would implement on a branch, I'd review, request adjustments, then merge. Vercel deployed from main on every merge.
Across the project so far that's 44 PRs and ~75 commits, spending roughly 25 focused hours by my estimate. In that time: cash session tracking (start, live, end, rebuys, breaks), history, edit/delete, a CSV importer for 525 sessions of historical data, a stats dashboard with cumulative bankroll and period-profit charts, tournament tracking with its own schema and UI, and a stats dashboard reworked to handle cash, tournaments, and combined views. I also asked Claude to build a public splash page for the app: parallax scroll, phone mockups, the Apple-style treatment.
A Few Things That Stood Out
100x engineer moment. You hear a lot of talk these days about the "100x engineer" replacing the old "10x" label. For a personal project like this, that's exactly what it felt like. 25 focused hours of work, and what came out of it is a real, full-fledged app, not a toy or a demo. The tournament feature is the clearest example. I'd paused the project for about six weeks after finishing the cash session side, and when I came back to build tournaments, the whole thing (live tournament tracking, history integration, stats integration, schema and migrations) came together in three sessions over a single weekend. Maybe three to four hours total. Live UI, history tab, full stats integration, all of it. Given that I'd been dreaming of building this app for years and got it done in 25 hours, '100x engineer' isn't really an exaggeration.
The frontend barrier collapsed. This was the biggest unlock for me. For years I had clear visions for what the UI/UX would be, but never had the frontend capabilities to execute. With Claude, the gap between I can see it and I can ship it effectively closed. That alone changes what a backend engineer can credibly build on their own.
Context management. Throughout the 11 weeks (and roughly 25 hours of actual time) of this project, I had the same Claude Code terminal open. The context window filled up and compacted multiple times, and yes, occasionally it would forget something I'd told it earlier. But for the most part, I was able to avoid context rot by having Claude record decisions in SPEC.md and CLAUDE.md as we went, and Claude also persisted things in its own memory across compactions. What impressed me was being able to work on this in discrete one-hour sessions across multiple weeks, and have it still feel cohesive. Like I was working with a partner who remembered everything we'd built together.
Architecture conversations were genuinely useful. Claude wasn't just generating code. It was a sounding board for schema decisions, state management trade-offs, and edge cases. The patterns documented in CLAUDE.md (server components fetch, client components interact; bottom sheets mount conditionally so they reset on open; tournaments share locations and game_types but not stakes) came out of real back-and-forth, not boilerplate.
Judgment and human oversight still matter. Two examples worth sharing.
About a week in, I noticed sessions weren't factoring food, tips, and time charges into the result, even though the formula was clearly specified in SPEC.md. I asked Claude what happened. Its answer:
"I implemented computeResult as a simple cashOut − buyIn early on and never went back to reconcile it against the SPEC formula. The SPEC was clear — I just didn't follow it carefully enough."
It fixed the bug, but I had to catch it. A proper test suite would have caught it earlier, something I plan to add as the project matures.
Another time, Claude was mid-feature on a branch when I asked it to commit and ship an unrelated fix first. It did, then came back to the original branch with the in-progress changes gone. It re-applied them from memory; I had to re-test to confirm they were actually identical. Without a keen eye on what was actually committed where, that's exactly the kind of silent regression a faster, looser workflow would ship.
Neither failure is damning. They're the kind of thing a fast junior engineer might do. But they're a reminder that even with how powerful these tools have become, human judgment, intuition, and a careful eye still matter. At least for now.
What's Next
The app is live at jackten.app (Why? The project codename and the GitHub repo name is jt-suited. JT are my initials, and it happens that Jack Ten suited is also one of my favorite poker hands). It's a PWA, installable on the iPhone home screen so it feels native. I'd eventually like to build a proper native iPhone version for a snappier feel.
The more interesting question is whether to take it further than personal use. I've toyed with the idea of opening it up to other players, maybe with a Pro tier for advanced features (variance modeling, opponent profiles and player notes, AI-powered session analysis). I don't know yet. For now it's a tool I built for myself, and I'm happy with that.
In the meantime, I'm headed to the World Series of Poker in Las Vegas this weekend, a summer trip I've been making for years. I shipped tournament tracking just in time for the trip, and I'm excited to put it to use at the most prestigious tournament series in the world. ♠️❤️♣️♦️