Overview
Sponsored Giveaways connects purchases made during a Whatnot show to a managed giveaway queue and an OBS overlay. It also handles live interactive HTML games that viewers control through Whatnot chat, with Firebase connecting the chat interaction to the games streamed through OBS. It helps the operator see who's waiting, whose turn is active, and which turns are complete without juggling a separate list during the broadcast.
The problem
A live host is already handling products, buyers, and the pace of the show. Sponsored giveaways add another moving sequence: someone purchases a turn, waits, gets recognized on screen, and eventually has their giveaway completed. I wanted the software to keep track of that sequence and show the right information during the broadcast.
My role
I built this application as the sole developer, owning the workflow design, implementation, integration, and testing. I defined the workflow from actual show situations and used Codex to help build and refine it. I checked how purchases were interpreted, asked what should happen in edge cases, and pushed for fixes when the saved state didn't match what the queue was supposed to do.
How I built it
The giveaway workflow connects a Chrome extension that observes Whatnot activity, a local Node service that manages the queue and controls, and an OBS browser source that displays the active sponsor.
The queue moves through Pending, Active, and Complete states. Matching giveaway events advance a turn, while manual controls handle situations that can't be matched safely. Local persistence and Firebase synchronization help the system recover after a reconnect instead of blindly replacing its current state. Show selection follows the focused Whatnot tab so a background tab doesn't unexpectedly change the broadcast display.
Live chat-controlled HTML games
The application also handles interactive HTML games during live shows. Viewers use Whatnot chat to control the games, Firebase connects those interactions to the game experience, and OBS streams the games as part of the broadcast.
This extends the application beyond sponsor tracking: the audience can participate in the on-screen experience while the operator manages the giveaway workflow. It brings live chat interaction, browser-based games, and broadcast presentation together in the same system.
The tricky part: one order is not always one turn
I asked a simple question during development: if somebody purchases a quantity of two, do they get two giveaway turns? The extension showed the quantity, but the queue was still creating only one entry for the order. Completing that entry finished the whole order.
I had the behavior corrected so a quantity-two purchase creates two turns. Completing the first leaves one pending; completing the second finishes the order. Duplicate purchase messages also have to preserve that progress instead of adding turns back. The release work recorded passing quantity tests and a Chrome integration check.
Event order matters too. Notifications can repeat or arrive late, and a completion must belong to the correct giveaway run. Stable identities and explicit state changes are safer than treating every incoming message as a brand-new instruction.
The result
The extension, queue controls, and overlay work as connected pieces of the giveaway workflow, alongside live HTML games controlled by Whatnot chat through Firebase and streamed through OBS. The quantity correction is a concrete example of making the saved behavior match what a customer actually purchased. The system still needs live-show validation as Whatnot's event structures change.
What I learned
Some of the best test cases come from ordinary questions about how people use the software. 'What if they buy two?' exposed a real problem that a correct-looking interface didn't reveal. I'd continue testing reconnects, delayed events, and multi-turn orders together, and make it easier for operators to see why a queue entry changed state.