Why We’re Building TestFlight for PC Games

Nayan Kumar — Sun, 16 Aug 2026 20:43:15 +0000

When we started building Userplay, we thought the hard part of playtesting was going to be getting players into the game. We were wrong.

Getting someone a build is one small part of the problem. The rest is everything around it: finding the right players, managing them, figuring out who's already tested the game, sending keys, getting NDAs signed, collecting feedback, watching recordings, following up. Then doing it all again for the next build.

Most studios already had a tool for each of these things. The problem was everything in between.

We started with the players

One of the first things we noticed was how much information about players ended up scattered. A Discord username in one place. A spreadsheet somewhere else. Survey responses in another tab. Notes about previous playtests living in someone's head.

It made it hard to answer basic questions — who has tested the game before, who gave useful feedback last time, who's been quiet for a while.

So we built the Player CRM. We didn't set out to build a CRM, but we kept hitting the same wall: you need some understanding of your players before you can run a good playtest.

Once we had that, waitlists and eligibility rules followed naturally. So did grouping players and keeping their history in one place.

For studios whose communities already live on Discord, we added a Discord integration. And once we started thinking about the full process of bringing someone into a test, Playtest NDAs became an obvious piece.

Getting players into the game was its own problem

Having the right players doesn't mean they're playing yet.

Different builds, different groups, different keys, different access rules. We saw teams tracking all of this in spreadsheets — who should get which key, who already had one — and it worked, but it was another manual process sitting in the middle of every test.

We built Key Distribution to handle this. Studios can bring their own keys or import them from Steam and send them to whoever's been approved for a given test.

The more we built around distribution, the less the product looked like a tool for sending builds and the more it looked like a system for running the whole test.

We started supporting single-session, multi-session, and longitudinal playtests instead of treating every test as "send this build to these people."

Recording changed how we thought about feedback

This is where things got more interesting.

We'd see teams ask players why they struggled with something and get answers like: "I didn't know what to do." Useful, but thin. What happened right before they got stuck? What did they try? Did they miss something on screen, or did they interpret the mechanic differently than the designer intended?

A recording can answer those questions. Gameplay Recording captures what's happening during a session without requiring studios to change anything about their games.

But recordings created a new problem: nobody wants to scrub through hours of footage to find the thirty seconds that matter. So we built Gameplay Analysis to surface important moments, transcripts, and highlights — a way to get through sessions faster.

We hadn't planned this as a big feature from day one. It came from using the product ourselves and realizing that collecting more data isn't useful if it just creates more work.

Connecting the pieces

At this point we had players, playtests, gameplay recordings, and feedback. But we kept circling the same question: how much do you actually know about the person behind a piece of feedback?

A player says the tutorial was confusing. But maybe they've played the game ten times. Or maybe it's their first session. Maybe they've hit the same issue three times. Maybe they stopped playing five minutes later. Those details change how you read the feedback.

Surveys are part of this, but they're not the end of it. We want survey responses to sit alongside what we already know about a player and what happened during their session.

Player Insights is our attempt at that — putting feedback back into the context of the player rather than treating it as an isolated response.

Who was this player? What did they do? What did they say? What happened during the session? That combination is much closer to what a playtest actually tells you.

The work outside the game

A playtest doesn't end when someone closes the game. There's community communication, player follow-ups, recruiting for the next test, sharing what changed.

These tasks kept showing up around every playtest we looked at, so we added things like Announcements and integrations with Mailchimp.

The playtest itself turned out to be only one part of the workflow.

What we're building now

All of this is how we ended up thinking about Userplay as TestFlight for PC games. Find the players, get them into the right test, see what happened, collect their feedback, understand it in context, and use what you learned to run the next one better.

Userplay is early. Some of what we're building today came from problems we didn't know we'd have when we started, and every playtest shows us another part of the process that could work better.

If you're making a PC game and running playtests today, we'd love to hear how you do it — especially the parts that still involve spreadsheets, manual work, or a pile of tools that don't quite talk to each other.