Article

Game studios: get paid for your records

By TrustPast

Updated November 7, 2026

A game studio ships one thing the world sees and keeps a hundred things nobody does. The trailer, the store page and the build are public. The years of argument that produced them sit in the bug tracker, the chat, the playtest notes and the post-mortems. This page is for small studios, the ones with fewer than 30 people, that have been making games long enough to have that second pile.

The part most studio owners don’t know they have a price on is the working record, not the game. A buyer licenses records like these to train AI models, and what it pays for is how the work was done: the bug that took three weeks to find, the level that was cut after the third playtest, the sprint that slipped and why. The same test runs through four trades on what data buyers want from a trade business, and it reads the same way in a studio.

Here is what a studio keeps, what the buyer says it wants, what stays out, how the price is set, and which programme fits.

The records a game studio keeps

These are our examples, not a buyer’s list. Polyshares decides what it licenses, after it has read a sample.

The design document and its history. Every studio starts with some version of it: a pitch deck, a wiki, a long document that grew for two years. The current page says what the game is. The edit history says what it used to be, and the comments say who argued for the change. A design document with five years of revisions is a record of a team changing its mind on purpose.

The bug tracker. This is the spine of a studio’s record. A ticket opens with a report: the build number, the steps, what happened, what should have happened. Then the triage note, the priority, the first guess at a cause. Then the comments, which is where the reasoning lives. “Can’t reproduce on dev kit.” “Only happens after a save and reload.” “It’s the physics step, not the animation.” “Fixed in build 412, reopened in 418.” A ticket like that shows a problem being diagnosed, wrongly at first, then rightly. A studio of 20 that has shipped four titles may hold tens of thousands of them.

The sprint board and the milestone plan. The plan says what the team promised for alpha, beta and gold. The board says what actually got done each two weeks. The gap between them, with the notes on what slipped, is how a studio learned to estimate. Our project history page goes through why the plan beside the outcome is worth more than either alone.

The playtest notes. Every round of playtesting produces a page: what the testers did, where they got stuck, what they said, what the team decided to change. Put three rounds of notes for one level side by side and you can watch a design get fixed by evidence. A studio that kept them from every round has a record nobody else can make.

The chat. The design channel, the build channel, the late-night thread when the certification build failed. Slack or Teams is where the exceptions got handled and where the quick decisions happened that never made it into a ticket. The chat archives page covers which channels show how the work was done, and which are only lunch plans.

The build and code history. Each commit message, each pull request, each review comment that said “this will break the save system” and the fix that followed. Code review is reasoning in its purest form: a proposal, an objection, a change.

The post-mortems. Most studios write one after each launch, some after each milestone. What went right, what went wrong, what to do differently. A post-mortem is the studio grading its own judgment. A set of them across ten years shows which lessons stuck.

The live-ops record. For a game that kept running after launch: the patch notes, the balance changes and the reasoning behind each, the player support queue, the event calendar, the community feedback threads on the studio’s own server. A balance change argued for a week in the design channel, shipped, then partly reversed after the numbers came in, is a full decision cycle on the record.

How a feature became a shipped feature is the story these records tell together. A designer writes a one-page proposal. The team argues it in chat. It gets a ticket and an estimate. Playtest round one says it is confusing. The proposal is revised, the estimate doubles, a producer cuts a smaller feature to make room. Round two passes. A bug in it ships anyway and gets patched in week two. No single file holds that story. The tracker, the chat, the playtest notes and the patch notes hold it between them.

See your estimate

What counts, in the buyer’s own words

Polyshares doesn’t publish a page about game studios. Here is what its pages do say, and how it reads against a studio’s files.

On who qualifies, Polyshares’ home page says: “Any company with real operating history, in any sector.” It adds: “The length and texture of the record matter more than headcount or revenue.” A studio of 12 with eight years of tickets and playtest notes has length and texture.

On what counts, the home page says operational data is “The working record of the business. Slack, email, Drive, spreadsheets, CRM history, support tickets, design files, call recordings, accounting and ERP exports.” A studio’s design files and support tickets are both on that list by name.

On where the value sits, Polyshares’ data licensing page says: “The value is not in volume. It is in reasoning that was captured while the work happened.” And: “A support ticket that shows a problem being misdiagnosed, argued over, and finally resolved is worth more than a clean table of finished numbers.” A bug ticket reopened twice is exactly that kind of record. The same page says: “The messy working record is the point, not a defect in it.”

Polyshares publishes guides to the systems a studio runs. On Jira, it says a work item “records a piece of work from creation to resolution: the description, every status change, the comments between people doing the work and links to related items.” It adds that sprints, estimates and custom fields mean “A dataset can connect how work was scoped with how long it actually took and what it was blocked by.” That sentence describes a studio’s milestone history better than most studios describe it themselves.

On Slack, Polyshares says channels “hold the working record of how a team makes decisions. A question, the replies and the outcome sit in one thread with names and timestamps, which shows how real work moves from a problem to an answer.”

On GitHub, it says a repository’s history paired with pull requests and review comments “shows the proposed change, the reviewer’s objection and the fix that followed, not only the final code.”

On Discord, which many studios run for their players, Polyshares says “Company-run Discord servers often hold support threads, product feedback and questions answered by staff.” It also notes that “Each person controls their own Data Package, and Discord does not let anyone export another member’s messages,” so plan on the staff side of those threads, not the whole server.

What the buyer does not want is just as plain. Polyshares’ page on what a record is worth lists the things that cap or kill the number, and one of them is “material that is already public, published, scraped, or widely syndicated.” The shipped game, the trailer, the patch notes on the store page and the public forum are already out there. The internal record behind them is not.

What is never included

Some of a studio’s files never belong in a licence. Our page on what is never included goes through them for every kind of company. In a studio, they sit in these places.

Players’ personal details. The account emails, the usernames tied to real names, the support emails with a player’s address in the signature. Polyshares’ data handling page says: “Names, emails, phone numbers, account numbers, and addresses are removed or replaced by a specialist PII partner before Polyshares or any buyer sees the record.” They were never what the buyer pays for.

Payment details. Store receipts, refund requests with card digits, the payments dashboard. As our own advice, keep them out of anything you describe at intake, and raise them on the call.

Young players. If your game is played by children, the support queue and the community server may hold messages from them. As our own advice, raise it with Polyshares before you apply and ask counsel. Don’t guess.

What a publisher or a client owns. This is the big one for studios. A studio that made a game under a publishing deal, or did work-for-hire art, ports or co-development for another studio, may hold files that belong to someone else. Polyshares’ answer page on whether selling company data is legal says material held on behalf of a client under an agreement that assigns ownership to the client “cannot be licensed regardless of value, and only the contracts separate the two.” It calls this “the single most common reason a promising record turns out to be unsaleable.” Find the publishing and work-for-hire contracts before you count those years.

Staff files. Contracts, salaries, reviews, the HR channel. The Polyshares Jira guide notes that “You choose which projects are included, so security, HR or customer-specific projects can stay out.” The Slack guide says “You decide whether private channels and DMs are in scope at all.”

How de-identification works

Polyshares describes the order of things on its data handling page. First: “Nothing moves before an offer. Intake asks for record counts, not files or exports. Nothing leaves your systems until Polyshares has made an offer and you have accepted it.”

Then the specialist partner strips identifying fields. The page says “Roles, timestamps, and the work itself are kept.” So the bug ticket keeps its build number, its reproduction steps, its comments and its reopen history. It loses the tester’s name. The playtest note keeps what the tester did on the second level. It loses who the tester was.

Then a person reads the result. Polyshares says: “Someone on the team reads the anonymized sample before Polyshares prices the record.” If the partner reviewing the sample spots anything that reads as identifying, “the record goes back for another pass before pricing continues.”

Buyers never see who you are. “Listings are published without the company’s name, website, people, or exact locations.” And “Two named people are the only ones at Polyshares who see a company’s identity alongside its data.” For a studio, that matters in a specific way: a game’s codename or a character name could point back to the studio. Ask on the call how those are handled.

Polyshares also says you do not have to clean anything first. Its Jira guide: “You also do not need to clean or scrub an export. Polyshares handles anonymization before anything moves.” Our page on how de-identification works sets the whole process out step by step.

What decides the price

Polyshares publishes one range. Its home page says typical deals run “$100K to $2M and above” (indicative, not an offer). Its answer page on worth says where a record falls “depends on the depth of operating history, how much reasoning is visible in it, and whether the company can grant clean rights.”

It names four things that move the number up. “Length of continuous operating history.” “Visible disagreement and correction, because a record of people being wrong and then getting it right cannot be manufactured.” “A specialized domain.” And “clean rights, because provenance that does not have to be litigated is worth paying up for.”

Read that against a studio. Length is the years of the tracker and the chat, not the number of titles. Disagreement and correction are the reopened tickets, the cut features and the playtest rounds. Clean rights is the publisher question again: a studio that owns its own games outright has a simpler record to price than one that built most of its years on someone else’s property.

It names what caps the number too. “A short operating history is one, below which the record is too thin to be interesting at any price.” Records held but not owned. Personal information “woven through the record in a way that cannot be cleanly stripped.” And material that is already public.

Polyshares publishes four closed licenses on its case studies page, each a “Perpetual exclusive license to the operational record” that was “Anonymized before delivery”: a roofing company at $450,000, a general contractor at $300,000, a solar company at $275,000 and a global marketing agency at $110,000 (indicative, not an offer). None is a game studio, and Polyshares does not publish what sat behind each deal. It says: “We look at the record before we price it. We do not pay for something we have not seen.”

Our page on what decides the price goes through each factor. What a studio can do before applying is count: the tickets, the years, the channels, the playtest rounds.

Which programme fits

Polyshares is the programme for US companies with 29 or fewer people, which is most independent studios. A studio with 30 or more people, now or at its peak, or a studio based outside the US, goes to a different programme. Our estimate asks how many people work at the studio and names the programme that fits your headcount. The programme page for 29 or fewer sets out the line.

Under Polyshares’ terms the studio pays nothing: “No fee, no commission. We pay you.” A license “is not a sale,” and the company keeps “the business and the underlying data.” If terms are never reached, Polyshares says “there is no fee at any stage, no exclusivity while we talk, and no obligation to proceed.” Have your own counsel read any license before you sign; Polyshares says the same.

Studios sit close to other companies that make things for an audience and keep a long trail of how they got made. Video production studios keep the same kind of revision history, cut by cut, with a client’s notes in place of a playtester’s. Consumer brands and photo studios keep the creative brief, the rounds and the approvals, much as a studio keeps its art reviews. And digital health companies run the same tracker-and-chat machinery as a studio, with a product that ships in releases and gets patched after launch.

TrustPast

Questions and answers

Does the buyer want the game itself?

Not the shipped game. Polyshares lists material that is already public, published, scraped or widely syndicated among the things that cap or kill a record’s value. The working record behind the game is what its pages describe paying for.

Do our Jira tickets count?

Polyshares publishes a guide for counting and exporting Jira, and says a work item records a piece of work from creation to resolution, with every status change and the comments between the people doing the work. Polyshares decides what it licenses after reading a sample.

What about a game we made for a publisher?

Polyshares says material held for a client under an agreement that assigns ownership to the client cannot be licensed regardless of value, and that only the contracts separate the two. Have counsel read the publishing agreement before you count those years.

Do player accounts and support emails go to the buyer?

Polyshares says names, emails, phone numbers, account numbers and addresses are removed or replaced by a specialist PII partner before Polyshares or any buyer sees the record. Raise player data, and anything about young players, with Polyshares and your counsel before you apply.

What do studios get paid?

Polyshares says typical deals run $100K to $2M and above (indicative, not an offer). It reviews the record before it quotes, so a range is not a price for your studio.

Do we need to export anything to apply?

No. Polyshares says intake asks for record counts, not files or exports, and that nothing leaves your systems until it has made an offer and you have accepted it.