From Spreadsheet to App in a Weekend

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:

  1. SPEC.md as the source of truth for what to build and why. Iterated heavily upfront, updated whenever the product evolved.

  2. CLAUDE.md for project conventions, architecture decisions, and patterns I wanted enforced. I told Claude to update both docs whenever it opened a PR that changed them.

  3. 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. ♠️❤️♣️♦️

Hiring and AI

Some observations and thoughts on my recent experience in trying to fill a role in today’s landscape of AI.

AI is progressing fast and is changing how we all approach software development. It’ll be fascinating to see how software systems and applications will be built and maintained in the next few years. As such, the use of AI has been highly encouraged across Gametime and we are investing heavily in Engineering, whether it’s using AI development tools or finding opportunities to build agentic solutions and foundations.

Now where it gets tricky is hiring. It would be hypocritical to say that on one hand Gametime believes in AI, then on the other hand, say that use of AI during the recruiting or the interview process is prohibited. Having said that, I believe there are some unwritten rules that all revolve around the core aspect of authenticity:

➡️ Using AI to help tailor your resume to specific job postings: Fair game in my opinion EXCEPT if you are lying. I came across a resume that was clearly generated to match our job description as it contained a lot of backend-specific accomplishments we were looking for. When I checked their LinkedIn profile, turned out they were a frontend engineer with zero mention of any of the same tech/projects that were on their resume. 😏

➡️ Using AI tools during your interview: If the company says you can’t use it, you may disagree but you shouldn’t use it. If they don’t say one way or another, you should tell the interviewer that you are using AI assistance (while writing code for example). This will provide a clearer context for all parties during the interview.

➡️ Fake candidates - I don’t even think this falls under the topic of AI, but thought it was worth mentioning. I recently interviewed a candidate that I ended up turning down (not the best communicator, some odd backtracking of statements, and clearly looking at a different screen while performing the coding exercise). 2 months later, I interviewed “another” candidate, and lo and behold, the SAME PERSON logged on. Needless to say, that was an interesting moment.

I’ll wrap this up by saying that at the end of the day, as a hiring manager, I’m trying my best to get to know a candidate through the interview process. Yes, engineering interviews are flawed and hard to get right, but as a candidate, if you are not being honest and authentic, what does that say about you? Sure, you might get the job but more likely than not, whatever made you feel the need to hide the truth will come out at some point during your employment with the company.

And yes, I used ChatGPT to proofread this for spelling/grammatical errors but the essence of this post comes from my authentic self. AI has been a polarizing topic, so I'm curious to hear your thoughts and experiences.

Finally, I’m still looking to fill a Senior Backend Engineer position on my team so please spread the word!

Moneyball == Big Data

 

Brad Pitt as Billy Beane in MoneyballBeing born and raised in Oakland, I've been an A's fan since I was a little kid.  So when I watched the movie Moneyball last year, lots of memories, both thrilling and painful, were brought back to life on the big screen.  I was at the game where Scott Hatteberg hit the game winning HR to give the A's a record-setting 20 consecutive wins.  I was also at the game where Jeter made that incredible tag at home plate that was probably the turning point of that series, which the A's eventually lost in 5 games to the Yankees.  What the A's were able to achieve during that era was absolutely incredible.  A bunch of kids with a team salary that was 20-25% that of the mighty New York Yankees, and yet they competed and made the playoffs 4 straight years (2000-2003 seasons).

As I think about it now, what's fascinating about the Moneyball philosophy that Billy Beane and A's have made so famous is that it's essentially what many tech companies have been and are trying to conquer.  Yes,

Moneyball == Big Data

In today's age of Facebook, iPhones, fitness tracking devices, etc., data is ubiquitous, and companies are trying hard to make sense of this data.  For example at my company, SumAll (shameless plug), we have built an app that takes data from various verticals (e.g. shopping carts, web traffic, payments, social, etc.) and combines them into a single, clean interface, allowing customers to better understand trends and patterns in their business.  The A's were able to overcome their financial disadvantage by being smart and examining data.  We think our customers can benefit the same way.

SumAll

Fast forward to 2012.  Many experts predicted that the Oakland A's would lose over 100 games this year.  Why?  Because the team let go of 3 top pitchers from last year, 1) Gio Gonzalez, 21 game winner and Cy Young favorite, 2) Trevor Cahill, and 3) All-star closer Andrew Bailey.  This year's team is a bunch of no-name kids with the LOWEST PAYROLL IN THE AMERICAN LEAGUE.  Sound familiar?  

Yesterday, on Oct 3rd, 2012, the final game of the season, the A's completed an improbable run to win the American League West division by sweeping the Texas Rangers, a team that has represented the AL in the World Series the last two years.  Incredible.  Regardless of what happens in the playoffs, the fairytale season of the 2012 Oakland Athletics is already worthy of a Moneyball sequel.

I'll end with some fun stats and observations:

  • The Oakland A's had an opening day payroll of $55,372,500, the lowest in the American League.
  • The New York Yankees had an opening day payroll of $197,962,289, the highest in the AL.
  • The A's finished with a record of 94-68, 2nd only to the Yankees at 95-67.  I guess that extra game was worth the $142M.  =P
  • Dan Szymborski's preseason projections had given the A's a 1.4 percent chance of making the playoffs and 0.4 percent chance of winning the division.
  • Las Vegas oddsmakers had the A's at 100-1 odds at the All-Star break to win their division.
  • On June 30th, the A's were 37-42 and 13 games behind the Texas Rangers.
  • With 9 games left, the Rangers were 5 games ahead of the A's.
  • The only time the A's were in sole possession of 1st place in the division was after winning the final game.
  • The A's lead the league with 14 walk-off wins.
  • After losing the aforementioned 3 top pitchers, the A's went on to lose 4 more pitchers (McCarthy, Anderson, Braden, and Colon), leaving them with the current starting rotation of ALL ROOKIES.  Amazing.
  • With the San Francisco Giants also making the playoffs, there's a possibility of another "Bay Bridge" World Series, which the A's of course won via a sweep in 1989.  =]