An experience problem that became a platform.
Stryde Game Hub is a live-event game platform designed for corporate events, conferences, networking events, churches, and community gatherings. Its flagship format is a head-to-head survey game that gets branded and renamed for each client. This is how it was designed: what the problem actually was, who the three users turned out to be, and the decisions that made it reusable instead of a one-off.
- Discipline
- Product development
- Product
- Stryde Game Hub
- First deployment
- ConnectFest XGames 2026
- Status
- Built · deploys Aug 21, 2026
A template would have worked. It just wouldn’t have been good.
Event planners already have ways to run a game-show segment. A slide deck with click-through reveals. A generic trivia tool. A spreadsheet for scores, and a laptop open on stage. These work, in the sense that the segment happens.
What they don’t do is make running the room easier. The reveal stalls while someone hunts for the right slide. Scores drift because they’re tracked by hand. The host gets anchored behind a laptop. And when something goes wrong, the audience gets to watch the recovery happen.
MPowered Productions needed a head-to-head survey game for ConnectFest XGames 2026, branded to the event and run live in front of an audience. The obvious build was one deck for one event. That’s the version you throw away on August 22.
There isn’t one user. There are three.
The thing that changed the build was noticing that “the game” is three different jobs, and they actively conflict.
The audience needs to see the board and nothing else. The host needs to see everything the audience can’t: every answer, every point value, every control. The organizer needs neither; they need to load questions and branding days before anyone walks into the room.
Build that as one screen and you get the failure everyone has watched happen: the answer key on the projector, the host squinting at a laptop, the stray click that reveals the wrong thing.
Three users, three surfaces. Every decision after this one followed from it.
Admin & Event Config
Before doors open
Questions, answers, branding, game title, and sound pack: loaded and saved as configuration, not authored live.
Host Controller
Phone · Sends actions
Reveals, strikes, scoring, round changes, undo. Sees every answer and point value the audience cannot.
Session State
Shared document · Single source of truth
One live record per game: revealed answers, strikes, scores, active team, current question.
Joined by short code
Audience Screen
Venue display · Renders state and sound
The board, and nothing else. Audio plays here because this is the machine wired to the room.
Three surfaces, each showing one user exactly what they need.
Audience Screen
The room’s view
A fullscreen board on the venue display: the survey question, hidden and revealed answers, point values, strikes, and team scores. No controls. No answer key. No accidental UI.
Audio plays here because this is the machine wired to the venue sound system.
Host Controller
Runs from a phone
The host privately sees the question, every answer, and every point value, then reveals answers, applies strikes, manages scoring, advances rounds, and undoes mistakes.
Phone-first, so the host can work the room instead of standing behind a laptop.
Admin & Event Config
Set up before doors open
Organizers load questions and answers, set organization and event branding, logo, accent color, displayed game title, and sound pack, then open a session.
Everything that makes the game feel like this client’s game is configured ahead of time.
What the host sees
- Only you see this · Hidden on TV
- The question and every answer live on the host’s phone. Neither is ever sent to the board.
- Point values, revealed one at a time
- Each answer carries its score and its own reveal control, so the host paces the round.
- Undo, in the header
- The reversible path is one tap away from anywhere in the round, not buried in a menu.
- TV status · Q1 / 2
- The host can see whether the board is connected and where they are in the set.
- Buzzer devices
- Two phones stand in as team buzzers on the same session. The host arms them for a face-off and sees who got there first.
What the organizer sets
- Accent color, stored, not hardcoded
- One value drives the board and the dashboard, so a client’s color is a field rather than a fork.
- Game title, previewed live
- The branded name shows on the board, the host controller, and the app title. Left blank, it falls back to the platform default, and an event can override it.
- Sound pack, selected per organization
- The audio identity is picked here rather than wired into the game, and an event can override the organization’s choice.
What a live room demands from software.
A live event is an unusually strict runtime. No retry, no support ticket, no “we’ll patch it tonight.” These constraints shaped the product more than any feature request did.
- Constraint: A mistake can’t be explained to a roomWhat it forced: Host actions are reversible
- Constraint: Nothing private can reach the projectorWhat it forced: Surfaces separated by role
- Constraint: The host shouldn’t need a laptopWhat it forced: Phone-first controller
- Constraint: Venue setup has to be fastWhat it forced: Short join codes
- Constraint: Audio has to come from the presentation deviceWhat it forced: Sound plays on the audience screen
- Constraint: Content can’t be authored liveWhat it forced: Everything loads before doors
- Constraint: Branding changes per client and per eventWhat it forced: Branding is data
- Constraint: It can’t be rebuilt for every clientWhat it forced: One platform, configured
The decisions underneath.
Reversible actions
Every host action is written to a log the controller can walk backward. An accidental reveal or a wrong score is corrected without the room learning there was a mistake, and because undo deliberately doesn’t re-trigger audio, the correction lands silently.
Separated surfaces
Audience, host, and admin are distinct interfaces, not one interface with permissions bolted on. Answer variants, host talking points, and scoring internals are never sent to the audience screen, so they can’t leak onto a projector.
Live synchronized state
One session record holds revealed answers, strikes, scores, the active team, and the current question. Every connected device reads from it, so the board and the controller can’t disagree about what has happened. The face-off buzzers are simply two more clients on that same record.
Join codes
Screens and controllers pair to a session with a short code. Setup at a venue is typing a few characters on whatever display is already there, not configuring devices.
Branding as data
Logo, wordmark, accent color, displayed game title, and sound pack are stored per organization and per event. A new client is a record, not a fork of the codebase.
Title and brand fallback
An event’s title, logo, and accent override the organization’s, which fall back to the platform default. A client who doesn’t care about naming gets something sensible; one who does gets exactly what they asked for.
Sound referenced by role
Cues are addressed by what they mean (reveal, strike, round win, face-off) rather than by filename. Swapping an entire audio identity is a configuration change, not a code change.
Reusable game architecture
The result is one platform that gets configured per client, rather than a new build per client.
Because branding, questions, and configuration are data, bringing on another organization or event is setup rather than custom development.
Built with
Nuxt
Application architecture across all three surfaces, and the foundation for progressive web app delivery.
Nuxt UI
The interface system behind the host controller and the admin dashboard, where dense controls have to stay legible under pressure.
Convex
The shared real-time session state every connected device reads from.
Progressive web app delivery
Browser-delivered to phone, laptop, and venue display. Sound packs and interface assets are cached after first load, so a shaky venue connection can’t drop a cue mid-show.
Custom animation
Purpose-built board reveals, strike slams, stage lighting, score transitions, and entrance choreography, written for a screen an audience is watching rather than a screen a user is operating.
Why real-time state
Convex holds the shared session behind each game, keeping the audience board and the host controller in agreement as answers are revealed, scores change, strikes land, and rounds advance. It also settles the one genuine race in the room: the face-off buzzers are phones on that same session, and because writes are serialized, the first buzz to commit wins while every later press does nothing. No client timestamps, no tie to adjudicate from the stage. Configuration behaves differently on purpose: questions, branding, and sound are written ahead of the event and read in when a session opens, while the session record itself changes many times a minute with a room watching.
The stack followed the experience. Real-time state is there because several screens have to agree about what just happened. Progressive web app delivery is there because the host needed a controller in their hand without asking a venue to install anything. Custom animation and sound are there because Game Hub isn’t only software people use. It’s software an audience watches. None of that is a house style; it’s what this particular problem asked for.
ConnectFest XGames 2026.
The platform is built. Its first production deployment is ConnectFest XGames 2026, an MPowered Productions event, on August 21. In that room, the game is branded ConnectFest Feud.
First production deployment
ConnectFest XGames 2026
- Client
- MPowered Productions
- Date
- August 21, 2026
- In the room
- ConnectFest Feud
Built and verified
- Three separated surfaces
- Reversible host actions
- Synchronized session state
- Join-code session entry
- Branding, titles, and sound as configuration
Planned for August 21
- Live deployment, August 21, 2026
- ConnectFest Feud branding in the room
- Audience, host, and organizers running it live
This page will be updated after August 21 with what actually happened. Until then it describes no results, reactions, or outcomes, because there aren’t any yet.
Why this is on a software company’s site.
Game Hub isn’t here because Stryde is becoming a game company. It’s here because it’s the clearest example of the full arc, on a product that didn’t exist before.
It started as a question about a room: how do you make a live segment feel produced instead of improvised? It ended as a platform that gets configured for the next client instead of rebuilt. Designed and built by Stryde Digital, founder-led from product definition through implementation.
Sometimes the output is a business operating system. Sometimes it’s a product nobody has built yet. The path is the same.
- 01
Problem
- 02
Product thinking
- 03
UX
- 04
System architecture
- 05
Production
Have something that doesn’t exist yet?
Game Hub started as a problem someone could describe but couldn’t buy. That’s more common than it sounds: you know the experience, the workflow, or the operational problem in detail, and nothing on the shelf actually fits it. Working out what should be built, and then building it, is the job.