Smash or Pass. Finally, a Version With Rules.

You've played it at parties, on couches, and in group chats for years. Someone pulls up a photo, chaos erupts, and thirty seconds later it's forgotten.

This version turns it into a real party game.

React + Vite + TypeScript
Firebase Firestore
Real-time listeners
Phase-based state
Play Smash or Pass →

Smash or Pass is the game we actually play when we're on the couch — or that's the goal. I create a room by topic (Celebrities, Cartoons, Athletes, Fictional, Wildcat), pick a subcollection, and friends join with a code. Each round, one player is on the hot seat and chooses smash or pass; everyone else guesses what they'll pick. Correct guesses pay out, wrong ones cost you, and the hot seat can trigger Hear Me Out — if their choice is the minority, guessers who got it wrong pay them. Everything is built so that later I can add smarter matchups or AI-generated prompts without rebuilding the core.

The Problem: When "Smash or Pass" Is All Talk

We've all done it: someone holds up a photo, everyone shouts smash or pass, and five minutes later nobody remembers who said what or who "won." There was no game — just noise. I wanted one place where the hot seat was clear, choices were locked in, and there was a real economy so that guessing your friends' taste actually mattered. No accounts required: room code, nickname, and you're in.

What If It Were a Real Game?

I started from a few questions:

  • What if one person had to commit (hot seat) and everyone else had to bet on them — so the game was about reading the room, not just your own opinion?
  • What if there were stakes (balance, payouts) so that being wrong hurt and being right felt earned?
  • What if the hot seat could "Hear Me Out" and get paid when the room guessed wrong — so going against the majority could be a power move?
Core question: How might I turn "smash or pass" from a meme into a playable, shareable party game with real structure and stakes?

What I Built First: Rooms, Rounds, Economy, Hear Me Out

I scoped the first version around what I could ship and still extend later: real-time sync, clear phases, and a scoring model that could support future twists.

  • Room creation and join — Host picks topic and subcollection, gets a room code; players enter code and nickname to join. Lobby shows who's in; host starts the game.
  • Round flow — Lock-in phase (hot seat chooses, others guess), reveal, then scoring. Balances update with animated +/- so everyone sees wins and losses. Roster of cards runs per topic/subcollection; when the deck is done, game ends and results show rankings.
  • Hear Me Out — Limited uses per game. Hot seat activates before reveal; if their choice is the minority vs. guessers, each wrong guesser pays them. Majority logic and payouts are computed server-side.
  • Persistence and real-time — Firebase Firestore for rooms, players, rounds, and choices. Subscriptions keep clients in sync so everyone sees the same phase and card.
  • Deployed — Frontend built and deployable (e.g. Vite build + static host or Netlify) so it can be shared and played for real.

Tech Stack (What's Actually in the Repo)

  • Frontend: Vite + React (TypeScript), React Router, Tailwind
  • Backend / data: Firebase (Firestore) — rooms, players, rounds, choices, card metadata; no separate API server
  • Game logic: Phase service, round service, choice service, scoring service, Hear Me Out service — all callable from frontend via backend utils
  • Cards: Nested Firestore structure (topic → subcollections → cards), with sample cards and initialization scripts

I built this with modern tooling — including AI-assisted development (e.g. Cursor) — to move fast and keep the architecture clear for adding smarter content or matchmaking later.

Design Direction: Social First, Smart Later

The goal is progressive complexity: get the core loop right (hot seat, guessers, economy, Hear Me Out), then layer in "smart" features that use context or AI without changing the feel of the game.

  • Memory and context — Remember who tends to smash or pass on which topics; suggest "you usually disagree with X here" or skew matchups. (Roadmap.)
  • AI-generated prompts or cards — Custom decks or prompts generated from a theme, so hosts can create "our friend group" or "2024 vibes" without manual curation. (Planned.)
  • Proactive flow — Suggest next roster or topic based on what's been played and who's in the room. (Roadmap.)

Why This Niche? Party Games That Actually Run

Most party games are either physical (cards, phones in hand) or fully digital with accounts and complexity. I wanted something in-between: join with a code, no sign-up, but with real-time sync and real stakes. Building around Firebase and clear phase logic meant we could play it in one room or over a call without the product getting in the way.

What Building This Taught Me

I focused on the job-to-be-done first: one hot seat, clear phases, locked-in choices, and an economy that made guessing matter. That gave me something playable and a data model (rooms, rounds, choices, balances) that can support personalization and AI later.

What's Next

Next steps are clear: add one AI-powered feature (e.g. topic or card suggestions from play history, or generated prompts), then explore memory so the game can say "this round is built to split the room." The goal is a party game that feels intelligent about the group, not just a fixed set of rules.

Built with React, Vite, Firebase (Firestore), and Tailwind. Prototyped and iterated with AI-assisted development (Cursor). Live app link above (replace with your deployed URL); source on request or via portfolio.