Most playtest tools confuse the people running the playtest (your team) with the people taking it (your testers). Playloop keeps them apart. Your team logs in, your testers never have to.
A workspace is yours. You own it, you pay for it, and you decide who else gets to log in. Invite your producer to keep an eye on the funnel, your designer to read the AI summaries, your QA lead to triage crashes, your publisher to scan the dashboard before each milestone meeting. Everyone sees the same data, with the right level of access for their job.
Workspaces ship with the paid tiers. Free accounts get a workspace too (with room for one collaborator), so you can try the invite flow before deciding whether Indie or Studio fits your studio.
Four roles cover about 95% of indie team shapes. No custom per-resource RBAC, no role builder. The whole permission model fits in the table below. Print it, tape it to a monitor, you’re done.
| Role | Best for | Can do |
|---|---|---|
| Owner | You, the studio founder | Everything. Manages billing, can delete games, can transfer ownership. Exactly one owner per workspace. |
| Admin | Producer, lead engineer | Configures the workspace: creates games, edits every game setting (name, events, symbols, AI tuning), and manages teammates. Does everything a Member does on playtest sessions too. Can’t touch billing, can’t connect integrations or outbound webhooks (those stay with the owner, alongside billing and provider keys), and can’t delete games or sessions (deletion is owner-only). |
| Member | Designer, QA, engineer | The operational role. Fully manages playtest sessions in the workspace: uploads sessions and assets (drawing on the owner’s storage and AI quota, not their own), runs analyses including bulk re-analyze, edits session details, exports, files issues from insights, hands out tester keys (generates, imports, and revokes them, manages invites), bulk-imports data, creates and edits feedback forms, acknowledges crashes. Does not change workspace configuration (game settings, event taxonomy, integrations, crash-notification webhooks), cannot delete games, cannot delete sessions, and cannot delete a whole tester-key batch (those deletions are owner-only). |
| Viewer | Publisher, advisor, external stakeholder | Strictly read-only. Sees dashboards, reads AI summaries, plays back recordings, and can export. Cannot manage playtest sessions at all: no uploading, analyzing, editing, or deleting. |
The same rules in matrix form. Scan a row, scan a column, it’s the same answer.
| Action | Owner | Admin | Member | Viewer |
|---|---|---|---|---|
| View dashboards, sessions, insights | ✓ | ✓ | ✓ | ✓ |
| Export a single session | ✓ | ✓ | ✓ | ✓ |
| Upload session assets (video, audio, screenshots) | ✓ | ✓ | ✓ | · |
| Run analyses (summaries, regen) | ✓ | ✓ | ✓ | · |
| Bulk re-analyze or bulk-export a selection | ✓ | ✓ | ✓ | · |
| Edit session details (title, tester, transcript) | ✓ | ✓ | ✓ | · |
| File an issue from an insight | ✓ | ✓ | ✓ | · |
| Bulk import | ✓ | ✓ | ✓ | · |
| Hand out tester keys | ✓ | ✓ | ✓ | · |
| Acknowledge a crash | ✓ | ✓ | ✓ | · |
| Create + edit + delete feedback forms | ✓ | ✓ | ✓ | · |
| Delete sessions (single or bulk) | ✓ | · | · | · |
| Create a game | ✓ | ✓ | · | · |
| Edit a game (name, genre, AI context, KPI, tuning) | ✓ | ✓ | · | · |
| Edit event taxonomy + per-event config | ✓ | ✓ | · | · |
| Upload + delete symbol maps | ✓ | ✓ | · | · |
| Invite teammates, change roles | ✓ | ✓ | · | · |
| Connect integrations + outbound webhooks (Slack/Discord, crash alerts) | ✓ | · | · | · |
| Delete a game | ✓ | · | · | · |
| Account settings (2FA, password, email change, account close) | ✓ | · | · | · |
| Billing + BYOK keys | ✓ | · | · | · |
The people playing your demo are testers. They never log in to Playloop. They get a tester key (a short code you share over Discord or in a build), the SDK picks it up, and every session that key fires is tagged with the tester's handle on your dashboard. That is the entire flow. Read more in /docs/tester-keys.
The people on your team are collaborators. They have Playloop accounts. They log in. They show up in the seat counter. These are the only people that count against the per-tier cap.
You can run a 200-tester playtest on the Free tier without touching your seat cap. The cap counts people on yourteam, not people on your contact list.
The owner counts toward the cap (you are the first seat). Pending invites count too, so an invite you sent but haven't had accepted yet still occupies a slot. Revoke it from /settings/team if you change your mind.
| Tier | Collaborators | Sized for |
|---|---|---|
| Free | 2 | Solo dev plus one collaborator |
| Indie | 3 | Two-to-three-person team |
| Studio | 10 | Producer-led indie studio |
From /settings/team, type an email, pick a role, hit send. We email them a one-shot link. They click it, sign in or sign up, and land in your workspace with the role you picked.
Invites are valid for 14 days. If the invitee misses it, just send a new one. Indie teams move slower than SaaS startups, so we set the window generous on purpose.
You can change a member's role any time. You can remove a member any time. Owners can't be removed (because then nobody would own the workspace), and there is exactly one owner per workspace.
Anything that touches an Admin (inviting someone as Admin, promoting a member to Admin, or removing an Admin) prompts a quick identity reverification first: the same modal you see for other sensitive changes. Inviting, changing the role of, or removing Members and Viewers doesn't prompt it. Those land instantly and show up in your audit log either way.
When a Member uploads a session in your workspace, the AI cost and storage charge against the workspace owner's tier, not the member's personal account. Same for retention, storage caps, and managed-AI quotas. The whole team draws from one pool.
That is the model: you pay once for your studio, your collaborators don't each need a paid tier. A Free-tier member invited into a Studio workspace gets the Studio quotas while they work in that workspace. They go back to Free when they work in their own.
If a workspace gets suspended (billing failure, policy dispute, abuse review), writes are blocked but reads continue. You can still browse, export your data, and read the AI summaries you already paid for. The dashboard surfaces a banner explaining what is happening and how to resolve it.
The point is to never lock you out of your own data while a dispute is being sorted. If you cancel outright, full data export is available right up until you confirm account closure.
Not in V1. A user can be a collaborator in multiple workspaces, but each invite is independent. Revoke in workspace A, invite in workspace B.
No. Viewers are strictly read-only by design. If a viewer needs to leave notes, promote them to Member.
Workspace transfer is on the roadmap but not in V1. If you need it sooner (selling your studio, founder change), email us and we'll handle it manually.
If you drop below your current seat count, existing collaborators stay. You just can't invite new ones until the seat count fits the new tier. We do not silently boot people you already invited.
Never. Testers don't have Playloop accounts, don't count against seats, and don't see any Playloop UI. The only thing testers interact with is your game.
These docs are evolving. Playloop is in active development ahead of launch, so APIs and details may change as we polish.