The Buyer Kiosk
A board game store's card-buying counter ran on a doorbell and guesswork.
The situation
I work part-time at Cape Fear Games, a board game and trading card store in Wilmington, NC. We buy and sell individual cards; Pokémon, Magic: The Gathering, that kind of thing. The buying operation runs out of a back-of-house area where buyers evaluate collections and make offers.
Here's how it worked before: there was a smart doorbell at the counter. A customer who wanted to sell cards would press it. A buyer would walk up from the back. Then they'd spend the first few minutes just figuring out the basics. What game. How many cards. Buying or selling. What kind of product. The buyer often wasn't even the right person for that category, so sometimes they'd walk back and send someone else up. Meanwhile, other customers were waiting.
It worked. But it was slow, blind, and created friction for everyone involved.
What I noticed
The real problem wasn't the doorbell. It was that the buyer had zero context before walking up. Every interaction started from scratch. And the information they needed wasn't complicated; it was just a handful of questions that nobody was asking upfront.
I also noticed there was no record of these interactions. If a buyer needed to look back at what a customer brought in last week, or track patterns in what people were selling, there was nothing. Every transaction disappeared the moment it ended.
What I built
I designed and coded an iPad-based kiosk that sits at the counter. When a customer wants to talk to a buyer, they walk through a short question tree: what game, buying or selling, roughly how many cards. Takes maybe 30 seconds.
On the back end, a few things happen at once. The right buyer gets notified with context (not just “someone's at the counter” but “someone has a collection of 200+ Magic cards they want to sell”). They show up already knowing what they're walking into. A notification hits our Discord so everyone on shift has visibility. The system can print a receipt-style ticket (like a kitchen order in a restaurant) so there's a physical artifact of the interaction. And every visit gets logged into a searchable history.
I built the whole system as a full-stack web app: a Node.js/Express backend, a vanilla JavaScript frontend, Socket.IO for real-time communication between the kiosk and buyer notifications, and a SQLite database for logging every interaction. The iPads run it through the browser. But the design decisions mattered more than the code. The question tree is fully customizable so the buyers can change questions, reorder them, and adjust the flow without touching code. I added customizable sound effects for notifications (because a store with personality should sound like it). And I architected the whole thing to be white-label-ready for other game stores, card shops, or any retail business with a similar back-of-house buying operation.
What happened
The buyers now arrive at the counter prepared. The “who are you and what do you have” phase of the conversation is gone. The right person shows up for the right category. Customers spend less time waiting. And the store has a log of every buying interaction they can reference and learn from.
The white-label architecture means this isn't just a solution for one store; it's a product concept. The same friction exists at every game store, comic shop, and card-buying business with a back-of-house operation.
What started as “can you make the doorbell smarter” became a full workflow redesign. That's usually how it goes.