why i made this

hi. i’m tommy and i like building stuff.

This project started because I thought it would be funny to mix the feel of sports betting with volleyball. Not in a serious finance-bro way. More like: can I turn watching finals into a chaos-friendly, number-go-up, everybody-yells-at-the-same-rally kind of game?

Also, me and Michelle love working on anything related to UI, UX, and experiences. so pretty quickly this stopped being “just make a finals game” and turned into one of those projects where we kept asking, wait... what actually makes people care?

i originally copied the full sports-betting playbook.

The very first version leaned hard into the PrizePicks / sports-betting vibe. I built it like a proper betting product: lots of matches, lots of picks, coins, free bets, prediction bonuses, and all the “real app” machinery.

I even added an auto-bet option because the thing got so big that manually placing bets became annoying inside my own app. Which is usually a sign that maybe, just maybe, the product is cooking a little too hard.

i finished it and immediately realized it was too much.

I had a fully fleshed out product end to end, and honestly? It was impressive from a shipping standpoint, but not nearly as fun as I thought it would be.

i stripped out the toxic stuff on purpose.

This part matters to me. I didn’t just simplify the app for usability. I also removed things that felt unnecessarily toxic.

I did not want people cheering for mistakes, rooting against players, or feeling like the whole experience was about somebody losing. So I changed the framing.

i slept on it and woke up thinking about the finals page.

That was the whole pivot. I basically scrapped the giant version in a PR and said: let’s hone down on the finals only.

Once I did that, the whole thing snapped into place. There is always a finals match. There is always something to root for. There is always a clean ending. The scoring becomes manageable. The game becomes understandable.

big number fun. weird multiplier fun. watching-the-game fun.

I stole the UI language from gambling apps because, straight up, those apps know how to make numbers feel exciting. But then I had to make it understandable for people who don’t gamble.

Once I started compounding categories like kills, blocks, digs, and the weirder little volleyball moments, the tickets got funny in the best way. Now people are suddenly locked in on pancakes and tools and whatever unholy multiplier chain they created for themselves.

this had to work for the audience and for the scorekeeper.

The original round robin approach was brutal for both sides. Watching 90+ games was too much. Scoring 90+ games was even worse. Also, not knowing exactly who is playing when makes the whole system feel mushy.

Finals-only fixed that. One game. Clear participants. Clean ending. Then I chose stat categories that are actually reasonable to tally on a sheet while still being fun to sweat from the sidelines.

this thing came together in a pretty stupid amount of time.

The real weekend rhythm was more like Friday afternoon at volleyball writing ideas down, Friday 9pm-1am vibe coding after my brother's game, then Saturday 9am waking up with the new gameplan, and Saturday 6pm-7:30pm getting everything organized for deployment and retrospectives.

If somebody wanted to replicate this kind of sprint, these are the kinds of questions that actually moved the product forward. Not perfect prompts. Just the ones that changed the direction.

this became a case study for me and michelle.

Me and Michelle really love building anything related to UI, UX, and experiences. So this project ended up being bigger than “just make a finals app.”

It turned into a little lab for rapid development, design instinct, and human behavior:

way before ai, i already wanted to make weird audience games.

A long time ago I had this idea for a thing called Rock Paper Scissors Split or Steal. the whole point was to make a social game that people could all play through Twitch chat, and then every x minutes the game would resolve and tell you if you won based on how the different game mechanics mixed together.

I never fully turned it into the thing I saw in my head, but that idea has lived in my brain forever. So this volleyball app is not some random one-off. it’s part of a much longer pattern for me of trying to build weird interactive systems around live people, suspense, and “yo wait what happens next?”

open sauce taught us a lot about what actually gets people engaged.

We went to Open Sauce and learned a bunch of lessons from seeing people react to things in real time. Stuff like rizz me up plankton, roasting fish, and just generally absurd internet-brain energy made one thing really obvious: people are not that engaged when it is just about them.

People light up more when the experience is playful, weird, shared, and a little chaotic in a fun way. not because someone is getting singled out, but because everybody is in on the bit together.

i care about building cool stuff, but i also care about optimizing and not spending money for no reason.

On paper, yeah, I could host this on Vercel, spin up more backend stuff, add more moving parts, and make it feel like a full platform. That is a valid way to do it. I like technology. I like going deep. I like building the more optimized version too.

Eddie mentioned that he was hosting the other site in HTML, and that made something click for me. I kind of stopped and thought: hold on, this app is already so basic from an architecture standpoint. It is basically a Google Form write layer and a Google Sheet read layer. I can host this in HTML too. Watch this.

So that is kind of what happened here. We did both. One version let me play with the more app-like stack. The other version let me prove that you can get a lot done with plain HTML, Google Forms, and Google Sheets if you stay focused on the actual experience.

this is the part where i show where the stuff actually goes so it does not feel like fake architecture talk.

One thing I like when I read project pages is when somebody just shows me the map. Like, cool, where is the app hosted? where does data get written? what reads it back? so here is the plain version.

i built this with agents and learned a ton in the process.

I had never really coded this way with Claude before. This project was where I started playing with plans, skills, and spawning multiple agents to go solve separate pieces. That part was actually super interesting.

The big lesson for me was that making a good plan matters way more once you have agents running around. It’s not just about writing prompts. It’s about shaping the work so the tools can move in parallel without stepping on each other.

I used a ton of Claude, eventually hit limits, then swapped over to Codex and kept going. Honestly? Still figuring out what each tool is best at. But the larger conclusion is easy: I’m not going back to plain old base chat for coding if I can avoid it.

this project changed how i think about being a developer.

Before this, AI mostly felt like a cool tool. After this, it feels more like the shape of the job is actually changing. Not because the hard parts disappear, but because the leverage changes.

I think more of the work now becomes: deciding what should get built, breaking it down clearly, protecting the architecture, checking the mirrors, validating the result, and keeping the product fun and coherent while moving fast.

I wrote the longer version of these lessons into AI_FINDINGS.md in the repo because I think this stuff genuinely affects how I will work going forward, and honestly how other developers should think about the craft too.

if this became a real real app, there are definitely corners i would go back and clean up.

I made some totally intentional tradeoffs so I could ship this as static HTML and get it demo-ready fast. I do not regret that. But if this grew up into a bigger real product, there are obvious things I would tighten.

i’ll probably build that twitch idea next and turn it into an ios game.

Rock Paper Scissors Split or Steal still lives in my head rent free. now that I’ve done this project and pushed on the rapid design / social-game side again, I kind of want to go back to that one and actually make it real.

So yeah. there’s a very real chance that the next weird thing out of me is that game, except this time I actually ship it and probably make it for iOS.