Forem: Forrest Miller

Building a Virtual Team Activity That Works in Any Browser

Forrest Miller — Tue, 21 Apr 2026 18:11:49 +0000

Building a Virtual Team Activity That Works in Any Browser

Our team is remote. Fully distributed, five time zones, the usual. Every few weeks someone on the People team asks if we can "do something fun together." The options are always the same: Jackbox (someone can't install it), Kahoot (half the team groans), or a virtual escape room that costs $25/person and requires a purchase order.

So we built something instead. A multiplayer bingo game that works in any browser, needs zero installs, and starts with a shared link. Here's how it works under the hood, and why the constraints mattered more than the features.

The Constraint That Shaped Everything

The hardest part of virtual team activities isn't the game itself. It's the 15 minutes before the game where someone can't install the app, someone else needs to create an account, and the IT person on the call says the domain is blocked by the corporate firewall.

We set one rule: it has to work the moment someone clicks a link. No app stores. No sign-up forms. No browser extensions. If it doesn't work in the browser you already have open, it's not worth building.

That constraint eliminated most architectures. Native apps were out. Anything requiring authentication was out. Heavy client-side frameworks that break on corporate-managed Chrome installations were out.

What's left? A server-rendered page with a WebSocket connection for real-time gameplay.

How the Real-Time Part Works

Every bingo game is a room. When a host creates a game, the server generates a room code and a shareable link. Players click the link, land on the game page, and a WebSocket connection opens automatically.

Here's what travels over the wire:

Player joins → server sends them a uniquely shuffled board (same word pool, different arrangement per player)
Player claims a cell → broadcast to all players in the room
Player reacts with an emoji → broadcast immediately
Someone gets bingo → server validates the pattern and announces it

The important design choice: the server is authoritative. Clients don't decide if they got bingo. They send their board state, the server checks it, and confirms or rejects. This prevents the inevitable "I definitely had bingo first" argument.

Client A clicks cell → WebSocket → Server validates → Broadcasts to Room
                                                    ↓
                                            Client B sees claim
                                            Client C sees claim
                                            Host sees claim

We use WebSocket heartbeats to track who's still connected. If someone's browser goes to sleep (common on phones during Zoom calls), the connection drops and the player shows as inactive. When they come back, they reconnect and the server replays any missed state.

AI Content Generation: The Part That Saves 20 Minutes

The second friction point with team bingo is content. Someone has to write 25 squares. For a "things that happen on Zoom calls" card, that means opening a Google Doc, brainstorming with the team, arguing about whether "someone's kid walks in" is too obvious, and eventually giving up at 18 squares.

We built an AI content pipeline that takes a topic description and generates a full set of bingo clues in seconds. The model gets the topic, the grid size (3×3, 4×4, or 5×5), and returns clues that are specific enough to be funny but broad enough that multiple people can claim them.

The generation is streaming — clues appear one by one as the model produces them. Users can swap individual clues they don't like, which triggers a single-clue regeneration rather than rebuilding the whole card. This keeps the human in the loop without making them do the tedious part.

Why "No Account" Is a Feature, Not a Missing Feature

We went back and forth on this. Accounts enable saved games, player history, leaderboards across sessions. But accounts also mean:

Someone in IT has to approve a new SaaS tool
GDPR compliance for European team members
Password reset emails when someone forgets their login before the next game
One more entry in the company's vendor management spreadsheet

For a team activity that happens every few weeks, the overhead of accounts kills adoption. So we made accounts optional. You can create one to save your cards, but players never need one. The host shares a link, people click it, they play.

This is the same reason the game works without a native app. Every friction point — every "download this first" or "create an account to continue" — loses a percentage of your team. By the time you've lost 3 people to setup friction, the game isn't fun anymore because the room is too small.

The Printing Path (For When WiFi Fails)

Not every team activity happens on a video call. Some offices do in-person team lunches. Some teams meet up at offsites. We added PDF generation that produces up to 200 uniquely shuffled boards — same content, different cell arrangements — that you can print and play with markers.

The PDF generation runs server-side. The client sends the card content and grid size, the server generates the PDFs with randomized layouts, and returns a downloadable file. No client-side PDF libraries, no browser compatibility issues.

What We Learned

1. Distribution beats features. A game that works instantly via link beats a game with 50 features that takes 10 minutes to set up. We could add tournament brackets, persistent leaderboards, team scoring. But none of that matters if three people can't join.

2. The host experience is the bottleneck. Players just click a link. The host has to create the game, pick a topic, configure the grid, and share the link. Every second of host setup time reduces the chance they'll do it again next month.

3. Corporate networks are hostile to fun. Firewalls block unknown domains. Chrome extensions get disabled by policy. App installations require admin approval. Building for the browser — specifically, building something that works on a locked-down corporate Chromebook — is the only reliable path.

4. WebSocket reliability matters more than WebSocket performance. Nobody cares if a cell claim takes 50ms or 200ms to propagate. They care a lot if the connection drops during the game and they lose their progress.

Try It With Your Team

If you want to run this with your own remote team, BingWow is the tool we built. Completely free, no account needed for players, works in any browser. Type a topic, share the link in Slack or Zoom chat, play for 10 minutes.

The best team activities are the ones that actually happen. And they only happen when the setup cost is close to zero.

How We Generate Bingo Cards with AI in 10 Seconds

Forrest Miller — Mon, 13 Apr 2026 18:14:15 +0000

Type "Super Bowl party" into BingWow and you get 25 themed bingo clues in about 10 seconds. Clues stream in one at a time while you watch. You can swap any clue with an AI-generated replacement, adjust the tone (playful vs. realistic), or edit the text directly.

Here's how the generation pipeline works.

The Streaming Approach

We use Google's Gemini API with server-sent events (SSE). The prompt includes the topic, desired tone, grid size, and any existing clues to avoid duplicates. Clues stream to the client as they're generated -- the board fills in progressively instead of making the user wait for all 25.

POST /api/templates/generate-clues
→ SSE stream of clues
→ Client appends each clue to the board in real time

The tone control gives users three options: Playful (puns, exaggeration, humor), Balanced (mix of funny and realistic), and Realistic (things that actually happen). The prompt engineering for each tone took more iteration than any other part of the system.

Why Not Just GPT-4?

We use Gemini for clue generation and Claude for content moderation. The split is intentional:

Gemini (clue generation): Faster streaming, cheaper per token, good at creative list generation. The clues are short (under 50 characters each), so the model's creative writing quality matters less than speed.
Claude (moderation): Better at nuanced content review. When a user-created card goes through moderation, Claude classifies it as KEEP, DELETE, or IMPROVE (rewrite + publish). The IMPROVE path rewrites inappropriate clues while preserving the card's theme.

Semantic Deduplication

A common failure mode: the AI generates "Someone scores a touchdown" and "A touchdown is scored." Same clue, different words. We run semantic dedup after generation -- computing embedding similarity between all clue pairs and replacing duplicates.

Background Image Generation

When you create a card, we also generate a background image via Replicate's FLUX Schnell model. The image goes through a text detection step (Claude Haiku vision) -- if readable text is detected in the image, we discard it and assign a fallback background. Text in background images makes clue text unreadable.

The full pipeline (clue generation + background image) completes in under 15 seconds. The image usually finishes before the clues.

Content Moderation Pipeline

Every user-created card runs through:

Deterministic checks (blocked words, spam patterns)
AI review (Claude classifies KEEP/DELETE/IMPROVE)
Auto-categorization (assigns the card to the right topic category)
Icon assignment (matches a Noun Project icon via embedding similarity)

Cards are playable immediately (even before moderation completes). The moderation runs in after() so it doesn't block the response.

Try It

Create a card on any topic in 10 seconds: bingwow.com/create

Browse 1,000+ pre-made cards: bingwow.com/cards

Everything is free -- no signup, no ads, no limits.

Building Real-Time Multiplayer Bingo with Next.js and Ably

Forrest Miller — Mon, 13 Apr 2026 17:30:33 +0000

I built BingWow, a free multiplayer bingo platform. Players open a link, get a uniquely shuffled board, and play together in real time. No app download, no account creation.

This post covers the interesting technical decisions: real-time sync, optimistic claims, server-side bingo detection, and why each player needs a different board.

The Problem

Traditional bingo generators give everyone the same card. In person that works because a caller draws numbers. Online, there's no caller -- players mark cells when they spot something happening (during a TV show, a meeting, a baby shower). If everyone has the same arrangement, the first person to mark a cell wins every time.

Each player needs the same clues in different positions. And claiming a cell needs to be instant (optimistic) while still being authoritative (server-verified).

Architecture

Next.js 16 with App Router (React 19)
Supabase PostgreSQL for rooms, players, boards, claims
Ably for real-time events (claims, bingo, round transitions)
Vercel for deployment

Board Generation

Every board is deterministic. Given a room seed and a player ID, the board is reproducible:

playerSeed = (roomSeed XOR hash(playerId)) >>> 0
playerRng = mulberry32(playerSeed)
positions = fisherYatesShuffle(nonFreePositions, playerRng)

The room seed determines which clues appear. The player seed determines where they go. Late joiners regenerate the exact same board by using the same seeds.

Wildcard Mode

In rounds 2+, each player gets ~2/3 shared clues and ~1/3 unique clues. This creates boards that overlap enough for shared moments but diverge enough that bingo timing varies.

Optimistic Claims

Tapping a cell marks it instantly. The server call is fire-and-forget for non-bingo claims:

Player taps cell
UI shows claimed immediately (optimistic)
POST fires to server (no await)
Server rejects? Next fetchGameState reconciles

For bingo-completing claims, the POST is awaited. The server's claim_and_process PostgreSQL function atomically inserts the claim, checks all winning lines, and updates the room status in one transaction.

Real-Time Sync

Ably handles event broadcast. The server publishes; clients subscribe. Events: claim, bingo, new-round, player-joined, chat. If Ably disconnects, clients call fetchGameState on reconnect to reconcile any missed events.

What I'd Do Differently

The claim system works but the fire-and-forget architecture means silent failures. If a claim POST fails (network error), the player sees a claimed cell that the server doesn't know about. It self-heals on the next state fetch, but there's a visible "unclaim" moment that confuses users.

If I rebuilt it, I'd use a write-ahead approach: persist claims locally first, then sync. But for a free tool with casual gameplay, the current approach is good enough.

Try It

The whole thing is free -- no ads, no paid tier, no signup required.

Create a card: bingwow.com/create
Browse 1,000+ cards: bingwow.com/cards
For teachers: bingwow.com/for/teachers

I Built a Real-Time Multiplayer Bingo Engine with Next.js, Supabase, and Ably

Forrest Miller — Fri, 10 Apr 2026 21:10:09 +0000

[BingWow](https://bingwow.com) is a free multiplayer bingo platform. You type a topic, AI generates a card, and up to 20 people play together in the browser. No downloads, no accounts. Teachers use it for classroom review games, event planners use it for baby showers and team building, and watch party hosts use it for live TV events.

Here's how the real-time multiplayer works under the hood.

## The Stack

- **Next.js 16** (App Router) on Vercel
- **Supabase** (PostgreSQL + Auth + Storage)
- **Ably** for real-time pub/sub
- **Tailwind v4** for styling

## The Hard Problem: Simultaneous Bingo Claims

Most of the game is simple. A player taps a cell, the client marks it optimistically, and a fire-and-forget POST goes to the server. No waiting, no blocking.

The moment it gets complicated is bingo. When a claim completes a line, you need to atomically determine who won. Two players might complete their lines within milliseconds of each other. The server has to pick one winner and broadcast the result to everyone.

We solve this with a Supabase RPC function called `claim_and_process`. It runs in a single database transaction: insert the claim, check if it completes a line, and if so mark the round winner. The atomicity of the transaction means two simultaneous bingo claims can't both win.

## Board Generation: Deterministic Randomness

Every player needs a unique board, but late joiners need to reconstruct the exact same board a player would have gotten had they joined at the start. We solve this with seeded PRNGs.

The room gets a random seed at creation. Each player's board is derived from `(roomSeed XOR hash(playerId))`. The hash function is FNV-1a, the PRNG is Mulberry32. Both are deterministic: same inputs, same board, every time.

This means we never store boards in the database. Any client can reconstruct any player's board from the seed and player ID. Late joiners derive their board locally and overlay the current claim state from a single `game/state` API call.

## Wildcard Mode: Shared Clues with Individual Variation

In wildcard mode (always on for online play), players share about 2/3 of their clues with 1/3 unique per player. The room RNG selects a "core" set, and each player's own RNG picks their variable clues from the remaining pool.

This creates the right balance: enough overlap that calling clues is meaningful, enough variation that copying someone else's board doesn't work.

## Real-Time Events via Ably

Every room subscribes to an Ably channel `room:{code}`. Events include `claim`, `bingo`, `new-round`, `player-joined`, `chat`, and `unclaim`. Claims are fire-and-forget from the server -- the DB is the source of truth, and Ably events are convenience notifications.

On reconnect after a disconnect, the client calls `fetchGameState` to reconcile any missed events. A heartbeat POST every 2 minutes keeps `last_active_at` fresh for the expiry cron.

## AI Card Generation

When a user types a topic on [bingwow.com/create](https://bingwow.com/create), we stream clues from Gemini via SSE. The user sees clues appear one by one as the AI generates them. They can edit any clue inline, change the grid size (3x3, 4x4, 5x5), or regenerate with a different tone.

Background images are generated in parallel via Replicate's FLUX Schnell model (~2 seconds), then screened by Claude Haiku for text artifacts before being attached to the card.

## What I'd Do Differently

**Skip the custom PRNG.** Mulberry32 was fun to implement but a simple `crypto.getRandomValues` with a seed would have been simpler. The deterministic requirement is real, but there are libraries for this.

**Use server-sent events for game state instead of polling + Ably.** Ably works great but adds a dependency. SSE from a Next.js route handler could handle the claim/bingo broadcasts with one fewer service.

## Try It

The whole thing is free at [bingwow.com](https://bingwow.com). Teachers can find classroom-specific guides at [bingwow.com/for/teachers](https://bingwow.com/for/teachers). The card creator is at [bingwow.com/create](https://bingwow.com/create).