Fat Bear Week HQ
A party app for one night and 20 friends: invites, potluck, and a live bracket game on phones and the TV. When the obvious game broke, I fixed it with a rule instead of code.
fatbear.sprigbo.com ↗
01 – What
A small app with the personality of the event, built for one evening, about 20 friends, and a deadline that couldn't move: Friday, October 2, 2026.
Before the party: one link, no accounts. Guests RSVP, claim a potluck dish, and learn the bears from a field guide of 42 Brooks River bears, with the live Katmai cams alongside.
At the party: Bracket Night, a host-run live game played on three screens.
Phone: each guest joins with one tap, votes on every matchup, posts a line of trash talk, and places a Final Wager.
TV: the bracket poster fills in live as results are revealed.
Press box: the host's remote for pacing the night: open voting, lock the round, reveal, undo.
Results reveal in two beats, first the party's vote and then Katmai's real count, so the room reacts together.
Pair the practical with the delightful
Its look is a vintage wilderness sporting club crossed with a sports broadcast. The potluck sheet is a sign-up form with jokes in it. The bear guide gives non-fans enough context to have opinions. The status card tells you "YOU'RE ON THE ROSTER." The same logistics a spreadsheet would handle are presented as part of the event.
Now an archive
The party has happened. The live site is now a read-only record of the real night: the roster, the potluck, the votes, and the winner.
- Role
- Product, design, game rules, host
- Team
- Me + Claude Code agents
- When
- Sept–Oct 2026
- Built with
- Claude Design → Claude Code
15 of 17 players went all in on the Final Wager, and it flipped the lead.
02 – Why
Every fall, Katmai National Park runs Fat Bear Week: a public bracket where people vote for the brown bear that fattened up most for winter. I wanted to throw a party around it.
The party needed the usual logistics: who's coming, who's bringing what. It also needed a way to make a few dozen very similar-looking bears approachable to people who had never watched the bear cams. So instead of a group text and a spreadsheet, I built a small app with the personality of the event.
What guests can do
- RSVP
- one link, no accounts. Pick your name or add it, tap I'm in, and come back to change your answer, say how many you're bringing, or declare a bear allegiance for pre-party trash talk.
- Potluck
- a curated menu of on-theme food (salmon, smoke, berries, honey, anything bear- or forest-shaped). Each dish can be claimed once, enforced by the database, so two people can't both sign up for the gummy bears.
- Field guide
- profiles for 42 Brooks River bears from the NPS photo guide: how to identify each one, where they fish, and their Fat Bear Week record.
- Watch
- the live cams sit alongside the guide, so guests can find a bear in the guide and then watch it fish.
03 – Three decisions and what they taught me
Decision 01
Optimize for the room, not for scale
Identity is "tap your name." Accounts would have cost more participation than they protected.
The full story
The call
With about 20 friends, every feature asked how little a guest would have to do. Host controls sit behind a shortcut link instead of a login, a tradeoff that only works for a small, trusted group.
What I learned
"No auth" is a decision that needs an expiry. The trust model that suited 20 friends on one night didn't suit a public link afterward. Archive mode closed it without adding accounts: it freezes everything, so anyone can explore the night without changing it.
Decision 02
Fix the game with a rule
You score by voting with the party majority, not by predicting Katmai's real winner.
The full story
The problem
The obvious game, predicting the winners, was broken. The official 2026 results were public by party night, so scoring against them would reward looking them up.
The call
Read the Room makes the game about reading your friends. Katmai's real count still decides which bear advances, so the bracket stays true to the real thing.
What I learned
A rule change can be the best feature. It fixed the game without adding code and made it more social.
Decision 03
Design around a fixed date
The party was on October 2, and nothing could slip.
The full story
The call
Coordination shipped first, about two and a half weeks out, so invitations could go out. Bracket Night shipped last, on the day of the party.
What made that safe
Rehearsal mode. The host can fill the room with bots that vote, talk trash, and bet, then jump straight to the Semifinal or Final to test the endgame.
What I learned
Rehearsal is a product feature. A live event gets one shot, and bots, jump-to-round, and undo let me run the whole night alone before anyone arrived.
How the night went
The night closes with a Final Wager and a tiebreaker question, if one is needed. Afterwards, an auto-generated recap covers the champion, the upsets, the closest matches, the all-in bets, superlatives and the quote of the night. The recap page was built the morning after.
17
players on the night
15
went all in on the Final Wager, and it flipped the lead
Known limits
Identity and host access run on trust: guests pick their own name, and the host link is a cookie, not authentication. Archive mode turns both off.
One party per deployment, with party content (date, bears, menu) hard-coded.
Polling and a per-instance cache suit about 25 players in one living room, not a public launch.
04 – How
Writing the spec is the work.
I designed the app in Claude Design and directed Claude Code agents to build it, reviewing and accepting every change. The parts that came out right the first time were the parts I specified most precisely: the game model, the reveal states, and the edge cases. AI implementation made the gap between a clear spec and a vague one obvious and immediate.
- Product
- the concept, the requirements and the game rules.
- Design
- the interaction and visual direction, iterated in Claude Design.
- Direction
- evaluating what got built, the tradeoffs, and testing.
- Host
- ran the event (and baked a truly excellent cake).
Tools, constraints & technical notes
The workflow
Explore the design with Claude Design. I directed the visual brand and interface over multiple rounds of iteration in Claude Design, ending with high-fidelity, interactive HTML prototypes with exact copy, colors and behavior.
Hand off a written brief. Once the design was set, Claude Design produced a design handoff and implementation brief for Claude Code. Those prototypes and briefs are in the repo's design reference. The Bracket Night brief is the clearest example: game model, scoring rules, edge cases and what the host sees at each step.
Build in the real stack with Claude Code. Each prototype faked persistence in
localStorage. The briefs explicitly asked for real server-side state.
Decisions that shaped it
The game engine is pure functions. Scoring, reveals, wagers, tiebreakers, undo and bot behavior live in one engine module, with no database or framework code. The persistence layer takes the database as an argument, so the tests run the same code against an in-memory Postgres (PGlite).
Concurrency is optimistic. The game is one row with a version number. Every host action is a compare-and-set, so a double tap or two host devices can't skip a step. The host has a full undo history for mistakes made live.
Polling, not WebSockets. Phones and the TV poll about once a second. With about 25 clients that's simple and robust. A 350 ms in-memory cache on the server collapses those polls into a few database reads per second.
Reliability where it mattered. Bear photos and the official results are stored in the repo, so the game didn't depend on a third-party site staying up during the party.
Archive mode. Setting one environment variable turns the deployment into a read-only record: the server refuses every write, nobody can sign in as a guest or act as host, and the UI points visitors to the recap. All data is left untouched.
Stack: Next.js 16, React 19, TypeScript, Tailwind CSS 4, Drizzle ORM, Neon Postgres, Vitest and PGlite, on Vercel.
Bear photos and identification notes are from the U.S. National Park Service (Katmai National Park & Preserve). Live cams are from explore.org. Official Fat Bear Week 2026 results are from explore.org and Katmai NP. This is a fan project, not affiliated with either.
Games · AI