Forem: Forrest Miller

Inline style attributes vs CSS variables: a Tailwind v4 light-mode debug story

Forrest Miller — Mon, 11 May 2026 18:06:40 +0000

TL;DR: I shipped a "light mode for the bingo caller" feature three times. Each attempt rendered as dark navy squares on a white stage — totally unreadable. The bug was the same every time: an inline style={{ background: hue.deep }} in a React component winning over the CSS class meant to control the background. Moving from inline styles to inline CSS custom properties unlocked a theme-aware cascade and finally made the feature ship.

The setup

I'm building a number bingo caller — the screen that flashes numbers across a board as they're called. Each column has a hue (Blue B, Red I, Green N, Orange G, Purple O). When a number is "called," that cell lights up in its column's color.

Dark mode shipped first. The visual goal: each called tile is a solid deep block — navy, crimson, forest, pumpkin, royal purple. Looks like a Las Vegas bingo board lit from inside. The implementation was the obvious one:

<button
  className="caller-tile caller-tile-called"
  style={{ background: hue.deep }}  // ← the bug, but I didn't know yet
>
  {num}
</button>

Worked great. Shipped.

The light-mode regression

Six weeks later I tried to add light mode. Visual goal: each called tile becomes a vibrant gradient lit from above — the same hue but the light end of its range, not the dark end. Think a bright pop instead of a moody glow.

I wrote the CSS:

.caller-tile-called {
  /* Light mode: linear gradient from highlight to mid */
  background: linear-gradient(180deg, var(--hue-highlight) 0%, var(--hue-mid) 100%);
}

.dark .caller-tile-called {
  /* Dark mode: solid deep */
  background: var(--hue-deep);
}

Set the CSS variables on each cell:

<button
  className="caller-tile caller-tile-called"
  style={{
    background: hue.deep,           // ← still here
    '--hue-highlight': hue.highlight,
    '--hue-mid': hue.mid,
    '--hue-deep': hue.deep,
  }}
>
  {num}
</button>

Reloaded the page in light mode. Dark navy squares. Crimson. Forest green. On a stark white stage.

I tried a few "make it work" patches. Increased CSS specificity. Wrapped the rule in :where(.light). Added !important. Nothing worked. The inline style={{ background: hue.deep }} was winning over my CSS rule every time.

I reverted the attempt and stayed in dark mode for another four weeks.

The two more attempts that broke the same way

Each time I came back to it I came up with a new theory:

Attempt 2: rewrite the CSS to target both .light .caller-tile-called and :not(.dark) .caller-tile-called. Same bug. Inline style still won.
Attempt 3: rewrite Flashboard to compute the gradient inline and conditionally render it. Forced me to thread theme state through three layers of React just to set a background: value. Also looked horrible because the inline gradient didn't get the var() indirection I wanted for component-internal tweaks.

After the third attempt I sat back and read the CSS specification on declared styles carefully.

Inline style attributes have higher specificity than ANY external stylesheet rule, including !important rules in stylesheets (unless the inline style is also !important). My background: var(--hue-deep) was authoring an inline declaration that simply couldn't lose. Every CSS rule I wrote was a bystander.

The fix was straightforward once I saw it: stop authoring background: in JSX entirely. Move the value into a CSS variable that the stylesheet picks up.

The shape that finally shipped

<button
  className="caller-tile caller-tile-called"
  style={{
    '--hue-highlight': hue.highlight,
    '--hue-mid': hue.mid,
    '--hue-deep': hue.deep,
    '--hue-glow': hue.glow,
  } as CSSProperties}
>
  {num}
</button>

.caller-tile-called {
  background: linear-gradient(180deg, var(--hue-highlight) 0%, var(--hue-mid) 100%);
  border-color: var(--hue-mid);
}

.dark .caller-tile-called {
  background: var(--hue-deep);
  border-color: var(--hue-mid);
}

The inline style now only sets CUSTOM PROPERTIES. Custom properties don't paint anything — they're just named values. The CSS rule consumes them and decides what to paint, and the CSS rule can switch between light and dark cases because it's the only thing actually authoring background:.

Light mode: gradient. Dark mode: solid deep. Both branches share the same hue palette. Switching theme is one class flip on <html>.

What I'd do differently from day one

I should have known this. I've answered Stack Overflow questions on inline-style specificity. The reason I missed it in my own code is that inline style={{ ... }} in React is so culturally adjacent to "just set the prop" that I didn't think of it as authoring a CSS declaration. It read as data, not as a stylesheet author.

The general rule I now keep on a sticky note: inline style should set values, not paint properties. CSS custom properties on the element are fine — they're values. Hex colors on background or color are dangerous — they're paint commands that no stylesheet can dethrone.

A side benefit

Once the hues were CSS variables instead of inline backgrounds, I could expose them to other parts of the component for free. The cell's box-shadow glow uses the same variables. The current-cell pulse animation uses --hue-glow. The ghost-number outline uses color-mix(in srgb, var(--hue-mid) 25%, transparent). Adding a new effect doesn't require touching React state — just touching the stylesheet.

Try It

Live in production — both modes work:

See the caller light mode: bingwow.com/caller (toggle theme in the navbar)
Create a multiplayer card: bingwow.com/create
Browse cards: bingwow.com/cards
Free, no signup, no premium tier: bingwow.com

If you've hit the same wall with theming a React component, I'd love to hear the route you took. Drop it in the comments.

Tailwind v4 dark mode: the @theme vs @theme inline gotcha that broke my contrast tests

Forrest Miller — Mon, 11 May 2026 18:06:38 +0000

TL;DR: in Tailwind v4 there are two ways to declare a color token in @theme. One compiles the hex value into your utility classes. The other emits a var(--...) reference that you can override from a wrapper class. Only one of these supports a multi-layer dark-mode cascade. I shipped six surfaces with invisible text because I picked the wrong one.

The setup

I'm running Tailwind v4 on a side project. Dark mode needs to do real work: I have always-light containers (white toast wrappers), always-dark containers (gradient heroes on otherwise-light pages), and components that flip per-theme (everything else). Plus a forced-colors mode for accessibility.

I started with the obvious thing: one @theme block declaring all color tokens, plus a .dark class with overrides. That works for backgrounds. It fell over the moment I tried to override token values from a wrapper class inside a theme.

The two `@theme` forms

Form	What Tailwind emits for `text-warning`	Override-able from cascade?
`@theme inline { --color-warning: #F59E0B; }`	`color: #F59E0B`	No. Hex is baked in.
`@theme { --color-warning: #F59E0B; }`	`color: var(--color-warning)`	Yes. Cascade wins.

This is undocumented in any obvious place. Both forms generate utility classes. Both work for "default" styling. The difference only shows up when a wrapper class tries to override the token.

/* This DOES work — token uses var() */
@theme {
  --color-warning: #F59E0B;
}
.surface-context {
  --color-warning: #B45309;  /* AA-pass amber-700 on amber-50 */
}

/* This does NOT work — token is compiled to hex inside text-warning */
@theme inline {
  --color-warning: #F59E0B;
}
.surface-context {
  --color-warning: #B45309;  /* ignored — text-warning was inlined */
}

The bug I shipped

My /research page had Industry-tier badges using text-warning on an amber-50 background. With text-warning: #F59E0B baked into the utility (amber-500), the contrast ratio was 2.06:1 against #FFFBEB. That's a WCAG AA failure — text barely visible to anyone, invisible to anyone with low vision.

Five other surfaces had the same shape: light surface context, default warning/gold/success token from the inline @theme, no way to nudge the token toward an AA-passing shade in that context.

The fix was a single move: take five tokens out of @theme inline and put them in @theme:

@theme {
  --color-warning:     #F59E0B;  /* default — amber-500 on dark */
  --color-gold:        #EAB308;
  --color-success:     #10B981;
  --color-danger:      #EF4444;
  --color-interactive: #6366F1;
}

.surface-context {
  --color-warning:     #B45309;  /* amber-700 on light — AA pass */
  --color-gold:        #A16207;
  --color-success:     #047857;
  --color-danger:      #B91C1C;
  --color-interactive: #4338CA;
}

.dark-surface-context {
  --color-warning:     #FCD34D;  /* amber-300 on dark slate */
  /* ... */
}

One change. Five surfaces fixed. CI contrast tests turned green across the route × theme matrix.

The 6-layer cascade

For tokens that need to flip across context AND theme, the cascade resolves in this order (later wins):

@theme         (default for class)
:root          (light-mode defaults)
.dark          (page-level dark)
.surface-context        (always-light container, even on dark page)
.dark .card-fun         (specific component override in dark mode)
.dark-surface-context   (always-dark container, even on light page)

The trick is that .surface-context lives ABOVE .dark in specificity by single-class, so a .dark .surface-context ancestor chain still wins via cascade order, not specificity. You don't need !important anywhere. You don't need dark:text-* overrides on individual elements. The wrapper class does the work.

The 17 text tokens that flip via .surface-context vs .dark-surface-context vs tooltip-dark are:

--color-text, --color-text-secondary, --color-muted, --color-heading, --color-link, --color-link-hover
5 overridable accent tokens (above)
6 surface-relative tokens (--color-border, etc.)

Most components never reference theme variables directly. They use the Tailwind utility (text-secondary, border-default) which compiles to color: var(--color-text-secondary). The wrapper class flips the variable. The element doesn't change.

What broke when I tried other shapes

Before this architecture I tried three alternatives. All shipped briefly and reverted.

dark:text-* Tailwind forks on individual elements. Worked for one component, became unmaintainable across 200+ surfaces. Every contrast fix required editing every callsite.
A second .dark block inside the cascade. Broke source order. The .dark class's later declarations clobbered earlier .surface-context overrides because they came after in the stylesheet.
!important on .surface-context token overrides. Felt wrong. Also broke when a child component needed to push a different value through (no precedence left to play with).

The thing that finally worked is "tokens live in @theme not @theme inline, wrapper classes override variables, utilities consume variables, no dark: patches anywhere."

Verifying it stays correct

I run a Playwright + axe-core matrix that probes 50 routes × 2 themes × 2 viewports = 200 scans on every CI run. If any token regresses (someone moves --color-warning back into @theme inline, or someone hard-codes a hex in a component), the contrast spec fails.

The lint that catches the worst class of regression — hard-coded #hex colors in component files — is a simple regex over the codebase that disallows anything except the design-system-blessed values. Every "I'll just use red here" attempt gets caught at PR time.

Try It

This is the design system powering BingWow, a free real-time multiplayer bingo platform. Light and dark mode are both first-class. Forced-colors works. The contrast matrix is at 100% AA pass on the latest deploy.

See it light + dark live: bingwow.com
A theme-heavy gameplay surface: bingwow.com/caller
For teachers, with AA-pass dark mode: bingwow.com/for/teachers
Browse 2,000+ cards: bingwow.com/cards

If you've solved the same problem differently in Tailwind v4, I'd love to read it — drop a link in the comments.

I added a grid_size column. Two months later I dropped it. What I learned about derived state in Postgres.

Forrest Miller — Mon, 11 May 2026 18:06:37 +0000

TL;DR: a grid_size INT column on three tables (rooms, players, card_templates) looked like a sane denormalization for a multiplayer bingo game. Two months later I deleted it on all three tables, because the value is tautologically encoded in another column already in those rows. Derived state at read time was simpler, smaller, and less buggy. Here's the trail.

The setup

I'm building BingWow, a free real-time multiplayer bingo platform. Each player has a board JSONB column that stores their cells: clue ids, positions, and image references. Boards are 3×3 (9 cells), 4×4 (16), or 5×5 (25). Mobile players are clamped to 3×3 regardless of the host's pick — it's an intentional product invariant.

When I first shipped flexible grid sizes in March 2026, I added:

ALTER TABLE rooms   ADD COLUMN grid_size INT NOT NULL DEFAULT 5;
ALTER TABLE players ADD COLUMN grid_size SMALLINT;            -- NULL = "use the room's"
ALTER TABLE card_templates ADD COLUMN grid_size INT
  CHECK (grid_size IN (3, 4, 5));

It read cleanly. Server endpoints did SELECT grid_size FROM rooms WHERE id = $1. The tap_claim RPC that runs on every cell tap dereferenced COALESCE(player.grid_size, room.grid_size, 5). All the bingo-detection logic could read one short integer instead of computing one. Win, right?

The bug class I kept hitting

Within six weeks I'd shipped four bugs traceable to grid_size drift:

Mobile clamp regression — a refactor wrote room.grid_size = 5 but generated a 9-cell board for a mobile player. Bingo detection then ran a 5-in-a-row check against a 9-cell array and threw out-of-bounds on every tap.
Resize-mid-game — when a player resized from Medium to Large mid-session, the new board got written but the players.grid_size column was only updated in one of three callsites. The fourth callsite (the auto-save on the cell-image edit path) overwrote the board without touching the column.
Fork inheritance — forks inherited the parent's grid_size but not always the parent's board. On rare race conditions a 4×4 parent produced a 3×3 fork that still claimed to be 4×4.
The "card is being set up" panel that fired when grid_size and jsonb_array_length(board) disagreed by exactly the time it took the auto-save to flush.

Every bug had the same shape: two sources of truth, drifting at different cadences.

The realization

grid_size is not independent state. It IS the board.

jsonb_array_length(board) = 9   →  3×3
jsonb_array_length(board) = 16  →  4×4
jsonb_array_length(board) = 25  →  5×5

Every callsite that wrote grid_size also generated the board at the same size in the same transaction. The two values were tautologically equal at write time. The bugs were all "we forgot to keep them equal" bugs.

The migration

Three sequential migrations dropped the column from each table. The most surgical one is the player-level drop, which had to rewrite the tap_claim RPC to derive grid_size from the board:

-- Before: COALESCE(v_player.grid_size, v_room.grid_size, 5)
-- After:  SQRT(jsonb_array_length(v_player.board))::INT
RETURN jsonb_build_object(
  'success',     true,
  'action',      v_action,
  'grid_size',   SQRT(jsonb_array_length(v_player.board))::INT,
  -- ...
);

ALTER TABLE players DROP COLUMN grid_size;

SQRT on integers in Postgres returns a double precision; casting to INT is exact for perfect squares 9, 16, 25. The cost is negligible — jsonb_array_length on a hot row is O(1) once the JSONB is parsed.

I kept the wire shape of the API unchanged. The HTTP response still emits player.grid_size: 5. Clients didn't change. The only thing that changed was where that integer came from.

What I'd do differently

I'd skip the column from day one. The instinct to denormalize "just in case the read cost matters" is hard to resist when you're staring at a query plan that reads two columns instead of one. The actual cost of SQRT(jsonb_array_length(board)) on a FOR UPDATE-locked single row is irrelevant — the network round-trip dominates by three orders of magnitude.

The thing I should have done is the thing I always tell other engineers and never do for myself: start with the simplest schema that encodes the invariant, only add denormalized columns when you have a profiled query that needs them. The invariant "grid_size is determined by board length" is structural. Encoding it in a separate column made the schema able to express illegal states, and every bug class I hit was a different illegal state realizing itself.

What I'd add to the schema instead

If you're going to keep computed values, encode them as GENERATED ALWAYS AS ... STORED columns. Postgres maintains them automatically, you can index them, and they can never drift:

ALTER TABLE players
  ADD COLUMN grid_size INT GENERATED ALWAYS AS
    (SQRT(jsonb_array_length(board))::INT) STORED;

I didn't go that route here because the derivation is cheap enough that I don't index on it. But it's the right pattern when you need both the simplicity of derivation AND the speed of an indexed read.

Try It

The whole codebase is live and used by real classrooms, party hosts, and senior activity centers. Built with Next.js 16, Supabase, Ably for real-time, Tailwind v4.

Create a multiplayer card: bingwow.com/create
Browse 2,000+ cards: bingwow.com/cards
For teachers: bingwow.com/for/teachers
Free, no signup, no ads, no premium tier: bingwow.com

If you've got a schema-bloat story or a column you regret adding, drop it in the comments. I'd love to read your trail.

We Audited 10 Team Building Platforms — Here's What HR Teams Actually Get for Free

Forrest Miller — Wed, 22 Apr 2026 19:07:08 +0000

I audited 10 team building platforms in April 2026 to answer the question HR teams actually care about: what do you get for free, and where does the paywall hit?

The findings are from a larger research report analyzing 7 years of Google Trends data, peer-reviewed meta-analyses, and a full feature audit. Here are the highlights.

Custom Branding Is Paywalled Almost Everywhere

Of 10 platforms audited, only 2 offer free custom branding — uploading a company logo and customizing colors without paying. Five platforms lock branding behind paid tiers. Three don't offer it at all.

For HR teams running branded team activities, this is the single most common hidden cost in the category.

The Subscription Trap Problem

One platform advertises a $2.95 trial that converts to $19.95/month. A Trustpilot reviewer reported being charged $260 over a year. For teams running one event per quarter, subscription pricing is misaligned with how these tools are used.

AI Generation Is the New Dividing Line

5 of 10 platforms offer AI-powered content creation. The ability to generate a custom team activity in 10 seconds vs. 30 minutes changes everything. Within 12 months, AI generation will be table stakes.

Printable Output Is Surprisingly Rare

Only 4 of 10 platforms support printing. Several add watermarks or cap free printable cards. For in-person events — all-hands, conferences, holiday parties — printed materials still matter.

Platform Highlights

TeamBuilding.com leads facilitated experiences with 25+ structured activities and trained hosts across major cities.

QuizBreaker offers the most comprehensive all-in-one suite: scheduled quizzes, DISC/Big Five psychometrics, escape rooms, pulse surveys, and peer recognition.

Donut has driven 15 million colleague connections through Slack — the most-adopted async tool for remote culture.

The Science Says It Works

A 2023 meta-analysis of 41 studies (5,071 participants) found gamified approaches produce a large effect size: Hedges' g = 0.822 compared to traditional methods (Li, He & Yuan, Frontiers in Psychology, DOI: 10.3389/fpsyg.2023.1253549).

Teams with regular team-building activities see 14% productivity increases and 23% profitability gains. For every $1 spent, companies report $4-$6 return.

The Trends

Google Trends data from 2019-2026 shows:

"Virtual team building" grew 736% and never came back down
"Office bingo" hit an all-time high in February 2026
"Gamification employee engagement" reached peak search interest in March 2026

Full Report

The complete report with interactive charts, 19 footnoted references, and CC BY 4.0 licensing:

The State of Team Building Games in 2026

BingWow Research Portal

I built BingWow as a free alternative — AI bingo card generation, multiplayer, company logo upload, printing. No subscription, no ads.

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 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, 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. Teachers can find classroom-specific guides at bingwow.com/for/teachers. The card creator is at bingwow.com/create.

Forem: Forrest Miller

Inline style attributes vs CSS variables: a Tailwind v4 light-mode debug story

The setup

The light-mode regression

The two more attempts that broke the same way

The shape that finally shipped

What I'd do differently from day one

A side benefit

Try It

Tailwind v4 dark mode: the @theme vs @theme inline gotcha that broke my contrast tests

The setup

The two @theme forms

The bug I shipped

The 6-layer cascade

What broke when I tried other shapes

Verifying it stays correct

Try It

I added a grid_size column. Two months later I dropped it. What I learned about derived state in Postgres.

The setup

The bug class I kept hitting

The realization

The migration

What I'd do differently

What I'd add to the schema instead

Try It

We Audited 10 Team Building Platforms — Here's What HR Teams Actually Get for Free

Custom Branding Is Paywalled Almost Everywhere

The Subscription Trap Problem

AI Generation Is the New Dividing Line

Printable Output Is Surprisingly Rare

Platform Highlights

The Science Says It Works

The Trends

Full Report

Building a Virtual Team Activity That Works in Any Browser

Building a Virtual Team Activity That Works in Any Browser

The Constraint That Shaped Everything

How the Real-Time Part Works

AI Content Generation: The Part That Saves 20 Minutes

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

The Printing Path (For When WiFi Fails)

What We Learned

Try It With Your Team

How We Generate Bingo Cards with AI in 10 Seconds

The Streaming Approach

Why Not Just GPT-4?

Semantic Deduplication

Background Image Generation

Content Moderation Pipeline

Try It

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

The Problem

Architecture

Board Generation

Wildcard Mode

Optimistic Claims

Real-Time Sync

What I'd Do Differently

Try It

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

The Stack

The Hard Problem: Simultaneous Bingo Claims

Board Generation: Deterministic Randomness

Wildcard Mode: Shared Clues with Individual Variation

Real-Time Events via Ably

AI Card Generation

What I'd Do Differently

Try It

The two `@theme` forms