VibeGrid
A daily asynchronous crew game: make one four-fragment vibe card, judge yesterday's cards blind, then reveal authors and votes.
What it is
VibeGrid gives a crew one creative constraint per day. Each person makes a named four-fragment card, judges the previous day's cards without author labels, and returns for the reveal. The suspense comes from interpretation and recognition, not from recovering a concealed answer.
The public homepage is a complete practice round, not a signup gate. Durable crews remain private, and the interface reveals only what the current stage and membership allow.
The loop it has to make believable
- 01
Reframed the product from a solitary answer-key puzzle into a private, asynchronous social ritual where the crew's interpretations are the point.
- 02
Made Go and Postgres authoritative for membership, stage timing, one-card and one-ballot limits, no-self-vote rules, ties, and result thresholds.
How it’s built
The Go service owns the social contract: immutable dated boards, authorization, submission and ballot transactions, staged projections, privacy, identity, and replay semantics. Postgres constraints reinforce same-round targets, one-card and one-vote rules, and no-self-vote behavior.
The exported Next.js frontend and migrations ship inside one non-root Go container. Operations include structured logs, health and readiness probes, bounded metrics, graceful shutdown, retention cleanup, and explicit production guardrails.
Architecture
- Board state
- An immutable dated palette whose row count freezes from the crew-size snapshot
- Make
- Exactly four fragments and one title, with one card allowed per member and board
- Judge
- Eligible makers see authors hidden and cast one non-self ballot
- Reveal
- Authors and votes appear only in the result stage; ties remain ties
- Identity
- Revocable hash-only browser bearers map to stable crew identities across leave and rejoin
- Runtime
- A Go binary embeds the exported Next.js frontend and migrations; Postgres owns the durable crew path
What has to hold up
- Used client replay IDs, database uniqueness, and stable member identities so timed-out retries or membership churn cannot reset product rules.
- Separated public practice from durable crews and added hash-only revocable sessions, CSRF protection, rate limits, health/readiness probes, metrics, and runbooks.
How I would present it
I would start with the three-day interaction and show how one card changes across make, blind judge, and reveal. Then I would trace the same rule through UI projection, Go authorization, the transaction, and the database constraint.
The strongest engineering discussion is about state that must survive retries and membership churn without leaking authorship early or inventing a result for a quiet round.
Proof
VerifyRepository, checks, stack, status
- 01
Open the GitHub repo and play the browser-only practice round described in the README.
- 02
Read the product vision and decision register for the make, judge, reveal contract and deliberate non-goals.
- 03
Inspect the round handlers, transactional store, stable-identity migration, and stage-specific privacy projections.
- 04
Run the documented service, security, Postgres, build, and smoke checks before making deployment claims.
- Role
- Product mechanic, staged interaction, transactional rules, identity, privacy, and operations
- Scope
- Private daily crew ritual with public browser-only practice
- Proof
- Product vision, decision register, service tests, migrations, smoke script, and runbooks
- Stack
- Go, Next.js, React, TypeScript, PostgreSQL, pgx, Tailwind CSS
- Loop
- Make → judge → reveal
- Crew size
- 1–20 members
- Retries
- Idempotent writes
- Runtime
- Go + Postgres