Players Engine

Devlog · Entry 04

Running a closed beta with Discord, Sentry and GitHub

· Nic Vannetti · 5 min read

The PlayersEngine beta is closed and invite-based: people request access on the landing page, and I onboard them in waves, each wave getting a code by email. Waves instead of a floodgate because every new group surfaces a new class of problems, and one person can only fix so many classes at once. This entry is about the pipeline that carries a player's "this is broken" all the way to a deployed fix — built entirely from three boring, proven tools.

Discord: where feedback starts

Every beta member lands in a private Discord server. The mistake I made in week one was using normal chat channels for feedback: bug reports, reactions and memes braided into one stream, with anything older than a day effectively gone. The fix was switching to forum channels — Discord's threaded format where every report is its own post.

The structure that survived contact with reality:

Forum posts get status tags (triaged, in progress, fixed) so anyone can see where their report stands without asking. Threads stay searchable, so "is this known?" has an answer that isn't scrollback archaeology.

Sentry: the reports nobody files

Most failures never get reported by humans — people hit an error, shrug, and close the tab. Sentry catches what they don't say. Every service and the web client report crashes with stack traces, release tags and enough context to reproduce. Three habits make it work for a team of one:

The best moments in the beta so far have been messaging someone "that crash you hit a minute ago — fix is deploying now" before they'd decided whether to report it. That's not magic; it's just plumbing that works.

GitHub: where work becomes real

Discord threads and Sentry alerts are inputs. Work happens in GitHub issues — every accepted report becomes one, labelled by severity: p0 (someone is blocked right now, drop everything), p1 (hurts daily use, this week), p2 (real but survivable, batched). A small automation bridges Discord forum posts into draft issues so good bug reports don't die of copy-paste friction; the issue links back to the thread, and when the fix ships, I close the loop by replying in that original thread.

That last step is the highest-leverage thing in the whole pipeline. People who see their reports cause visible change report more, and better. People who report into silence stop. Feedback culture is downstream of response culture.

What didn't work

For balance, the failures. Polls and "what should I build next?" questions produced enthusiastic wishlists with almost no relationship to how anyone actually used the platform — people are sincere and wrong about their own future behavior, me included. A long structured feedback survey got three responses, all from the same kind people who'd already told me everything in the threads. The pattern underneath both: asking generates opinions, watching generates truth. The pipeline above earns its keep precisely because it's built around what players do and hit, not what they predict they'd want.

The weekly rhythm

Monday is triage: every new thread, alert and issue gets read, labelled or politely declined. The week is for fixing in priority order. Friday is a digest in announcements: what shipped, what's next, which reports led to fixes — with names credited. Then a new wave of invites goes out, and the cycle starts again with fresh eyes.

None of this is sophisticated, and that's the point. The pipeline's job is to make sure that when a player gives me thirty seconds of their attention, nothing between Discord and production lets it fall on the floor.

← All devlog entries