# Playable Business — full text

> Playable Business is an independent publication explaining how games move from pitch to production, release, and ongoing support. It separates documented platform rules and public facts from editorial analysis, and it publishes no invented revenue, sales, leak, insider, or anonymous-studio claims.

# Video Game Crowdfunding: Pledges, Rewards and Risks

> Reward-based crowdfunding lets people pledge support toward a proposed game, sometimes selecting a reward such as a future game copy. This guide uses Kickstarter's rules, not a universal crowdfunding contract. Reaching a campaign goal does not guarantee completion, delivery or a refund. Read the specific reward, current platform terms and development evidence before committing money; obtain qualified legal, tax or financial advice for an actual campaign or dispute.

Source: https://gamingindustry247.com/crowdfunding-video-games-explained/  
Publisher: Playable Business  
Published: 2026-09-08  
Updated: 2026-09-08

## How does crowdfunding work for video games?

Reward-based crowdfunding lets people pledge support toward a proposed game, sometimes selecting a reward such as a future game copy. This guide uses Kickstarter's rules, not a universal crowdfunding contract. Reaching a campaign goal does not guarantee completion, delivery or a refund. Read the specific reward, current platform terms and development evidence before committing money; obtain qualified legal, tax or financial advice for an actual campaign or dispute.

## What does a pledge give a backer?

Kickstarter permits rewards and support without a reward; it prohibits equity, financial returns and loans. A pledge does not buy shares in the studio. The platform's [reward explanation](https://help.kickstarter.com/hc/en-us/articles/115005047953-What-do-backers-get-in-return) describes support for a creative project, not an investment account.

For a game, read the selected tier rather than assuming every pledge includes the same edition. Our editorial reading method separates five fields:

- **Deliverable:** game copy, soundtrack, physical item or support only.
- **Version:** named platform, edition and any account requirements.
- **Timing:** estimated reward delivery, distinct from campaign closure.
- **Conditions:** dependencies or limitations stated for that reward.
- **Additional charges:** what the page says about shipping or taxes.

A soundtrack tier is not a game tier merely because the campaign trailer contains gameplay. Record unanswered questions instead of filling them from the headline.

## Does a funded goal mean the whole game is paid for?

Kickstarter uses all-or-nothing campaign funding: if the goal is not reached, backers are not charged and the creator receives no campaign funds. Its [goal guidance](https://help.kickstarter.com/hc/en-us/articles/115005134293-How-to-set-the-right-funding-goal-for-your-Kickstarter-campaign) tells creators to account for completing the project, fulfilling rewards and associated fees. It also discusses creators who can complete the project regardless of the campaign amount.

Consequently, a goal can sit within a wider, disclosed financing plan. Do not infer that relationship from a small-looking number. Nor should a creator present an unexplained funding gap as solved by crossing the goal.

Ask: what work has already been financed, what does this campaign fund, and what money remains conditional? A hoped-for publisher agreement belongs in a different column from available cash. The [funding-route guide](/how-video-games-get-funded/) provides that broader context.

## Why can the public total differ from available cash?

Kickstarter's [dropped-pledge guidance](https://help.kickstarter.com/hc/en-us/articles/360034693434-What-happens-if-the-final-funding-amount-is-lower-than-the-goal-after-a-campaign-has-ended) says unsuccessful collections can reduce funds received, even below the campaign goal. The public campaign total is not updated to remove dropped pledges. Collected funds are also subject to fees.

Here is an original fictional accounting exercise, not an actual campaign, recommended goal or typical collection rate. Assume one-time pledges only, all denominated in dollars, with no shipping, add-ons or later pledges:

| Record | Calculation | Amount |
|---|---|---:|
| Campaign closes at its hypothetical goal | 100 pledges × $20 | $2,000 |
| Five pledges ultimately collect nothing | 5 × $20 | $100 |
| Successfully collected before deductions | 95 × $20 | $1,900 |

The $100 difference is uncollected support, not a development expense. The $1,900 is still not spendable development profit: this exercise has not deducted fees, taxes or reward costs. It deliberately does not calculate a payout.

For a creator's records, label the columns **pledged**, **collected**, **deductions** and **remaining obligations**. For an outside reader, leave unavailable figures unknown. The campaign display and a bank statement answer different questions.

## How can you read a campaign without inventing missing facts?

Use this original decision record. The entries are fictional examples, not findings about any studio:

| Evidence stated on the page | Record as | Question still open |
|---|---|---|
| A downloadable demonstration exists | A limited build is offered | Which promised systems are represented? |
| A console version appears in a future plan | Planned version | What dependencies and reward conditions are disclosed? |
| A delivery month is labelled estimated | Estimate | What work remains before that reward? |
| A physical art book is included | Separate fulfillment promise | Are production and destination charges explained? |
| Another funding application is pending | Conditional funding | What happens if that money does not arrive? |

Copy the page's actual wording into your own record with its date and link. Keep **shown now**, **promised later** and **unknown** separate. A polished trailer can communicate an idea without documenting the whole production state.

Our editorial threshold is clarity, not a numerical trust score. If the answer would change your decision, ask the creator before pledging or wait for stronger evidence. This method cannot certify a campaign.

## What would a useful question to the creator look like?

Use the record to ask one answerable question at a time. For the fictional console row, an editorial example is: “The reward names a computer version, while the roadmap mentions a console version. Which version does this tier include, and where are the conditions stated?” That is more useful than asking whether the studio is trustworthy.

For the fictional funding row, ask what the stated campaign amount covers and how the plan changes if the separate application is unsuccessful. Do not request private account information or assume the creator must disclose every commercial agreement. An unanswered material question remains an uncertainty, not evidence that an undisclosed deal exists.

Creators can use the same record in reverse: make the reward page answer the question before someone needs to send it. Separate current evidence from ambition and identify which update supersedes an older statement. This is an editorial communication framework, not a claim that we ran a campaign or measured its results.

## What should developers plan after the campaign?

Our proposed planning sheet connects every offered reward to an owner, remaining work, dependency and communication checkpoint. A digital copy and a physical book need separate rows even when bundled together.

For a hypothetical additional language, list translation, implementation and testing as distinct work to investigate. Do not assume extra pledges fund all added obligations. A stretch goal should be evaluated against its additional scope, costs and dependencies.

The [development-stage guide](/game-development-stages/) helps distinguish a demonstration from production, validation and release work. These are planning questions, not a cost estimate, launch schedule or assurance of commercial viability.

## How is this different from Steam Early Access?

Valve's [Steamworks documentation](https://partner.steamgames.com/doc/store/earlyaccess) says Steam Early Access must supply a playable game or usable software at purchase. It is not pre-purchase or a way to crowdfund development; customers should evaluate the current build, not promised future additions.

A campaign reward describing later access therefore needs a clear delivery stage. Do not treat a future key promise as evidence that a playable release is available now. For the release-state distinction, read the [Early Access guide](/early-access-games-explained/).

## What happens if delivery slips or the game fails?

Kickstarter's [creator-obligation guidance](https://help.kickstarter.com/hc/en-us/articles/115005028834-What-is-a-creator-obligated-to-do-once-their-project-is-funded) places responsibility on creators to complete promised work, fulfill rewards and communicate progress and delays. Responsibility is not a platform guarantee that the project will succeed.

Its [refund guidance](https://help.kickstarter.com/hc/en-us/articles/115005048173-Does-Kickstarter-issue-refunds) directs requests for collected pledges to the creator; Kickstarter does not itself offer refunds. A refund may be unavailable after funds have been spent.

Keep the reward description, relevant updates and correspondence. Use official creator/platform support for project questions. Those platform explanations do not determine every legal right in every jurisdiction; obtain qualified advice for an actual dispute rather than treating this article as a remedy or deadline guide.

## Sources

- [Kickstarter: backer rewards](https://help.kickstarter.com/hc/en-us/articles/115005047953-What-do-backers-get-in-return)
- [Kickstarter: setting a funding goal](https://help.kickstarter.com/hc/en-us/articles/115005134293-How-to-set-the-right-funding-goal-for-your-Kickstarter-campaign)
- [Kickstarter: totals after dropped pledges](https://help.kickstarter.com/hc/en-us/articles/360034693434-What-happens-if-the-final-funding-amount-is-lower-than-the-goal-after-a-campaign-has-ended)
- [Kickstarter: creator obligations](https://help.kickstarter.com/hc/en-us/articles/115005028834-What-is-a-creator-obligated-to-do-once-their-project-is-funded)
- [Kickstarter: refunds](https://help.kickstarter.com/hc/en-us/articles/115005048173-Does-Kickstarter-issue-refunds)
- [Valve: Steam Early Access documentation](https://partner.steamgames.com/doc/store/earlyaccess)

## Frequently asked questions

**Does backing a Kickstarter game make me an investor?**

Kickstarter prohibits equity, financial returns and loans; its reward-based model does not give a backer shares in the studio. Read the selected tier to see whether it offers a game copy, another reward or support without a reward. Other crowdfunding models have different terms and should not be treated as equivalent.

**Does reaching a funding goal guarantee the game will ship?**

No. Campaign funding and finished delivery are different events. Kickstarter places completion and reward responsibilities on the creator, but that does not guarantee success. Read current evidence, remaining work and the specific reward conditions. For an actual legal or financial decision, use qualified advice rather than a campaign percentage as assurance.

**Why might a creator receive less than the campaign total?**

Kickstarter explains that some pledges can fail to collect and that the public campaign total is not reduced for dropped pledges. Fees also affect the funds received. Our fictional accounting example distinguishes promised support from successful collection; it is not a typical failure rate, actual studio budget or complete payout calculation.

**Is a crowdfunding reward the same as Steam Early Access?**

Not automatically. A reward may promise a future copy, whereas Steam Early Access must provide a playable game or usable software at purchase. Valve says customers should evaluate its current state. Check exactly what the reward delivers and when; a future access promise is not proof that a playable release exists now.

**Can I get a refund if a funded game is not delivered?**

Kickstarter says it does not itself offer refunds and directs requests for collected pledges to the creator. A refund may not be possible if funds have been spent. Read applicable platform terms and project communications, and seek qualified legal advice for a real dispute; this summary does not determine your jurisdiction-specific rights.


---

# Early Access Games: What Players and Studios Should Expect

> An Early Access game is an unfinished but playable release offered while development continues. On Steam, it is distinct from a preorder, and customers should judge the current build rather than depend on promised features or dates. Players should inspect current content, update history, save compatibility, support, pricing, and refund terms. Studios need a playable value proposition, honest communication, structured feedback, reliable release operations, and funding that does not assume Early Access sales will finish the game.

Source: https://gamingindustry247.com/early-access-games-explained/  
Publisher: Playable Business  
Published: 2026-07-19  
Updated: 2026-08-25

## Early Access means buying the game that exists today

An Early Access game is a playable, unfinished release sold while development continues. The sensible buying test is wonderfully unromantic: **would the current build be worth the asking price if its most exciting roadmap item never arrived?** If the answer is no, the purchase depends on a promise rather than a product.

For a studio, Early Access is not merely a launch with fewer levels. It is a period in which development, customer support, community management, release engineering, and public communication all happen at once. That can produce unusually useful feedback. It can also turn every patch note into a tiny shareholder meeting, except the shareholders are asking why the inventory ate their sword.

Steam’s official Early Access rules describe the model as a way to sell a game that is playable but not yet complete. They also say it is not crowdfunding and should not be used as a preorder. Those distinctions matter because players receive the current build immediately, while future scope, schedule, and even completion remain uncertain.

## Early Access, preorder, and advance access are different

The labels often get muddled together, but the player is buying a different thing in each case.

| Model | What the player gets now | What remains uncertain | The useful question |
|---|---|---|---|
| Early Access | A playable, unfinished build | Features, balance, schedule, compatibility, and final scope | Is today’s build worth it? |
| Preorder | Usually a reservation for a future release | Final quality and sometimes the release date | Is there a reason to pay before reviews? |
| Advance access | Access shortly before the standard release, often as part of an edition or benefit | Launch stability and the value of the early window | Is a few days of access actually valuable to me? |
| Demo or playtest | Limited access that may be free, timed, or restricted | Whether progress carries over and whether access continues | What is this test designed to show? |

These are general descriptions, not universal store definitions. Platforms set their own terms, refund rules, disclosures, and labels. Read the current store page and the platform policy that applies to the transaction before paying.

## A player’s checklist starts with the current build

Marketing copy naturally looks toward the future. A careful evaluation looks sideways at what is already there.

### Check the playable scope

Look for a concrete description of modes, maps, systems, story content, multiplayer population requirements, and known limitations. “A deep survival experience is planned” tells you less than “the current build includes base building, two regions, and solo play.” The second description can be checked; the first mostly owns a nice coat.

Watch recent, unedited gameplay when possible. Screenshots and trailers can show the intended experience, but they are poor tools for judging menu friction, loading behaviour, repetitive loops, controller support, or how often the game falls over and pretends it meant to sit down.

### Read recent update history, not just the roadmap

A roadmap shows intent. An update history shows operating behaviour. Look at the recency and substance of patches, how the team explains delays or changed plans, and whether known issues are acknowledged. A quiet month is not proof of abandonment; development can be invisible for legitimate reasons. It is still information to weigh alongside the studio’s own communication.

Do not turn update frequency into a universal score. A small team shipping careful quarterly builds may be healthier than a team pushing frantic weekly patches. What matters is whether the cadence, scope, and explanation fit the project.

### Check saves, hardware, and multiplayer dependencies

Unfinished software changes underneath its users. Ask whether major updates may break saves, reset progression, raise system requirements, or change mod compatibility. For multiplayer games, consider whether the current experience depends on active matchmaking, regional servers, or enough friends buying in with you.

Back up local saves when the game and platform permit it. Cloud saves help, but synchronisation is not the same thing as a versioned backup. If a patch corrupts or migrates a save, a perfectly synchronised broken file is still broken with excellent punctuality.

### Treat price plans as plans

Some studios intend to raise the price as content grows; others may keep it steady or experiment with discounts. There is no universal Early Access pricing path. Read the developer’s current statement, then decide based on today’s price and build. Never buy merely because a possible future increase creates urgency.

Also check the platform’s current refund policy before purchase. Refund eligibility varies by store, region, payment method, play time, and other terms. Do not assume an unfinished game receives a special escape hatch.

## Studios need an operating plan, not just a roadmap

The production decision begins before the store page goes live. A team should be able to explain why public access improves this particular game. Useful reasons include testing a systemic design across varied play styles, validating balance with a broader population, learning how servers behave under real demand, or building content with structured community feedback.

“We need launch sales to finish the game” is a dangerous foundation. Steam’s rules explicitly say Early Access is not crowdfunding. More practically, unit sales are uncertain. A responsible plan identifies what can be delivered with secured resources and what changes if revenue is lower than hoped.

That financial model connects directly to the wider choice of [video game revenue models](/video-game-revenue-models/). Early Access describes a development and release state; it does not dictate whether the eventual game is premium, supported by downloadable content, subscription-based, or something else.

### Define the value of the current build

Before release, write a blunt inventory of what works, what is missing, and what regularly breaks. If the current build cannot stand on its own long enough for players to understand the core loop, public access may generate noise instead of insight.

The store description should match that inventory. Steam’s documentation warns developers not to make specific promises about future events because completion dates and planned features can change. Describe direction and priorities, but separate committed current functionality from hoped-for additions.

### Ask answerable feedback questions

“Tell us what you think” produces a magnificent stew of bug reports, design preferences, support requests, jokes, and arguments about whether a sword is technically a longsword. Better prompts are narrower:

- Where did new players stop understanding the crafting loop?
- Which strategy dominates after experienced players learn the economy?
- Can players identify the cause of a failed mission?
- Which hardware configurations produce repeatable crashes?
- Does a proposed control change solve the problem it targets?

Decide how feedback is tagged, combined with telemetry or test evidence, reviewed, and answered. Popularity is not the same as representativeness. The loudest forum thread may identify a genuine problem, but it cannot by itself reveal how widespread that problem is.

### Build a release process that can survive contact with players

Public development needs stable branches, reproducible builds, rollback plans, save migrations, crash reporting, and ownership for release decisions. A patch that fixes combat but damages thousands of saves is not an uncomplicated win.

Use staged testing where the platform and team permit it. Maintain test saves from older builds. Verify installation, updating, offline behaviour, controller input, localisation, achievements, and server compatibility as relevant. Record who can stop a release and what evidence triggers a rollback.

These tasks belong inside the broader [game development stages](/game-development-stages/), not in a frantic appendix added after the store page acquires a buy button.

### Budget for communication and support

Every public build creates questions. Assign owners for bug intake, moderation, patch notes, accessibility reports, refunds or billing handoffs, and serious community incidents. Developers can participate directly without making every programmer permanently available in chat.

Set a communication rhythm the team can maintain. A short update that distinguishes completed work, active investigation, changed plans, and unresolved uncertainty is more useful than a glittery countdown to a date nobody trusts. When plans change, explain what evidence changed the decision. Players may dislike the outcome, but they can understand the reasoning.

The division of labour may involve both a studio and an external partner; [game developers and publishers](/game-developer-vs-publisher/) often split production, financing, marketing, certification, and support responsibilities differently from project to project. Put the Early Access duties in writing instead of assuming the other party owns the awkward inbox.

## Roadmaps should express priorities without pretending to predict weather

A useful roadmap communicates direction, dependencies, and uncertainty. It may group work as current, next, and later rather than attaching dates to every feature. It should distinguish required work—such as stability, accessibility, save safety, and the path to a complete release—from optional experiments.

Avoid presenting aspirational art, platforms, modes, or integrations as guaranteed. If a feature depends on technical research, licensing, external approval, or community testing, say so. Changing a plan is not inherently a betrayal; hiding uncertainty until the change becomes impossible to miss is what burns trust.

Retire old roadmap images when priorities change. An outdated graphic will continue touring social media long after its context has packed a suitcase and left town.

## Leaving Early Access needs explicit criteria

“When it feels done” is not a release plan. Teams should define exit criteria appropriate to the game: core content complete, progression coherent, critical defects below an agreed threshold, saves handled safely, performance acceptable on supported hardware, required platform checks passed, and support ready for a larger audience.

The criteria need not make the game perfect. No honest release gate can promise that. They should make the decision reviewable. If the team changes the definition of completion, it should record why and update public expectations.

Early Access can be a productive agreement between a studio willing to develop in public and players happy to engage with an unfinished build. It becomes much less mysterious when both sides focus on the same thing: what exists now, what remains uncertain, and how changes will be handled. The roadmap can be exciting. The current build still has to pay the rent.

## Frequently asked questions

**Is Early Access the same as a preorder?**

No. A preorder sells entitlement before the product is delivered, while Early Access provides a playable unfinished build now. Steam explicitly distinguishes its Early Access programme from pre-purchase and from advance access, where certain editions unlock a finished or launch-bound game a few days early. Other platforms may use labels differently, so read the store definition.

**Does an Early Access game have to be finished?**

There is no guarantee that every Early Access game reaches a planned 1.0 state. Development can change, stall, or stop. Steam tells developers not to make specific promises about future events and tells customers to buy based on the current build. Evaluate current value, disclosed risks, update history, team communication, and store refund policy rather than treating a roadmap as delivered content.

**Can Early Access games raise their price?**

They can on platforms that permit it, subject to current rules. Steam says developers choose their pricing approach and should explain planned changes transparently; its discount restrictions can interact with a price increase. A lower current price is not universal, and a higher future price is not guaranteed. Check the game’s current store disclosure and platform policy before purchase.

**Will Early Access updates break save files?**

They may. Major system, data, world, or content changes can make saves incompatible, and platform guidance expects developers to disclose known breakage. Players should read update notes, preserve supported backups where possible, and avoid assuming cloud sync creates versioned recovery. Studios should define migration policy, test upgrades, label incompatible branches, and communicate before destructive changes.

**Is Early Access crowdfunding?**

Steam says its Early Access programme is not a way to crowdfund development and warns studios not to depend on selling a specific number of units to finish. Purchasers receive a current playable product, not merely a future promise. Other funding methods can coexist with development, but their legal, platform, and consumer obligations differ and should not be collapsed into one label.

**What should a studio measure during Early Access?**

Measure signals tied to explicit questions: build stability, crash patterns, onboarding completion, feature use, retention in relevant cohorts, save migration, support load, feedback themes, and whether the team can sustain its update process. Metrics need context and consent-respecting data practices. Do not present one loud forum thread or one peak player count as the entire community or product trajectory.


---

# Game Developer vs Publisher: Who Does What?

> A game developer builds the game: design, engineering, art, audio, production, testing, and related work. A publisher typically finances, markets, distributes, certifies, localises, supports, or commercially manages a release, but the split varies by agreement. A developer may self-publish; a publisher may own internal studios; an external studio may retain its company while granting publishing or intellectual-property rights. To understand a specific game, examine the credits, corporate ownership, public announcements, and contract—not the logo order alone.

Source: https://gamingindustry247.com/game-developer-vs-publisher/  
Publisher: Playable Business  
Published: 2026-07-19  
Updated: 2026-08-25

## Developers build the game; publishers build the route to market

A game developer performs the creative and technical work of making the game: design, engineering, art, audio, production, testing, and related disciplines. A publisher typically finances, markets, distributes, localises, certifies, supports, or commercially manages a release. That is a useful starting distinction, not a universal org chart. A developer may self-publish, a publisher may own internal studios, and an external studio may retain its company while granting particular rights under contract.

To understand one release, ask four separate questions: **who made which parts, who financed them, who owns the relevant rights, and who performs publishing work?** One logo card cannot answer all four, however impressively it whooshes onto the screen.

## Compare common responsibilities

| Work | Developer commonly leads | Publisher commonly leads | Can be shared or outsourced? |
|---|---|---|---|
| Game design and code | Yes | Internal publisher studios may do this | Yes |
| Art, audio, narrative | Yes | Sometimes through internal teams | Yes |
| Production and scheduling | Yes | Publishing producer may oversee milestones | Yes |
| Development funding | Sometimes | Often in funded deals | Yes |
| Marketing and public relations | Sometimes | Often | Yes |
| Store setup, pricing, distribution | In self-publishing | Often | Yes |
| Platform submission and certification | Developer supplies builds | Publisher may coordinate | Yes |
| Localisation and age ratings | Sometimes | Often coordinated | Yes |
| Customer and community support | Sometimes | Often shared | Yes |
| IP ownership | Contract-dependent | Contract-dependent | Yes |

“Commonly” matters. Company size, platform, geography, financing, genre, and agreement change the split.

## What a game developer actually contains

“Developer” can mean one person, an independent studio, a co-development specialist, a porting team, or a publisher-owned organisation with hundreds of contributors. It can also refer to the people doing the work or the company employing them.

Typical disciplines include:

- game and systems design;
- gameplay, engine, tools, network, and platform engineering;
- character, environment, technical, interface, and concept art;
- animation, visual effects, audio, music, and narrative;
- production and project management;
- quality assurance and development support;
- user research, accessibility, data, build, and release engineering.

Not every studio keeps every function inside. External partners may create cinematics, localisation, art assets, audio, ports, QA, accessibility review, or entire features. Full credits reveal more of that labour than a store-page developer field.

The [game-development stages](/game-development-stages/) show where these disciplines overlap from concept through post-launch work. A stage name does not belong exclusively to one company.

## What a publisher may contribute

A publisher can supply capital, commercial expertise, market access, operational capacity, or risk-sharing. In a broad publishing arrangement, its work may include:

- advances or milestone funding;
- production oversight and milestone review;
- market positioning, trailers, events, press, creators, and advertising;
- user research and audience testing;
- localisation, ratings, compliance, and platform coordination;
- manufacturing for physical editions;
- store relationships, pricing, discounts, and release operations;
- customer support, community management, fraud, and moderation;
- analytics, finance, tax, and revenue reporting;
- post-launch planning.

Some publishers perform only a subset. A label providing marketing and console submission is not economically or operationally identical to a company funding the full project and owning the IP.

Do not infer hidden deal terms from visible services. Unless the parties disclose the agreement, outsiders usually cannot know the advance, recoupment, rights, approval structure, or revenue split.

## Ownership and publishing are different axes

A publisher credit does not prove the publisher owns the developer. Common relationships include:

### Independent studio with a publishing agreement

The studio remains a separate company. The agreement may grant the publisher rights for certain platforms, regions, formats, languages, or a defined term. IP ownership and sequel rights depend on the contract.

### Publisher-owned internal studio

The studio is part of the publisher’s corporate group. It may retain a distinct brand and creative leadership, but corporate ownership connects them.

### Co-development or work-for-hire studio

A partner performs defined development work for another company’s project. It may not own the resulting game or public-facing publisher role.

### Platform publishing or funding relationship

A platform company may publish, fund, market, distribute, or secure exclusivity. Those roles can overlap without being identical.

### Self-publishing developer

The developer assumes publishing responsibility directly, hiring agencies or service companies where needed. “Self” describes control and contractual structure, not necessarily zero outside help.

## Follow the rights, not the vibes

Intellectual property can include copyright in code, art, writing, audio, trademarks, characters, patents, trade secrets, and contractual rights. Different entities may control different elements.

A licence may grant publishing rights while the developer retains underlying IP. A publisher may own the IP while a developer creates a game under contract. A licensed game may use a third party’s characters while the game code and new assets have their own ownership terms.

For a real deal, acquisition, or dispute, only the written agreements and applicable law settle the question. Public credits and copyright notices are evidence, but not a complete contract. Qualified counsel belongs in the room before signatures, ideally before the room has become a crisis room.

## Financing changes control, but not in one fixed way

Funding can arrive as milestone payments, an advance recouped from future revenue, a minimum guarantee, platform support, investment, loans, grants, crowdfunding, internal capital, or combinations. Each changes cash timing and risk.

Approval rights may cover budget, scope, milestones, platforms, price, marketing, release timing, or changes in control. A developer can retain creative influence in a funded deal; a self-funded developer can still face platform and market constraints. “Independent” does not mean free from all dependency.

Never infer a game’s budget from team headcount, visual style, or development duration alone. Labour mix, location, outsourcing, technology, marketing, overhead, and delays make outsider estimates fragile.

The [revenue-model guide](/video-game-revenue-models/) explains why gross spending does not reveal the money available to either party after platform share, refunds, tax, recoupment, costs, and contractual splits.

## Who controls the release date?

Control varies by contract and organisation. The studio estimates development readiness; publishing and marketing teams coordinate campaigns, platform submissions, retail or manufacturing, localisation, and commercial timing; platform holders impose technical and scheduling requirements.

A delay can reflect stability, scope, certification, dependencies, accessibility, localisation, market strategy, manufacturing, or several interacting causes. Without a sourced statement, assigning the motive to one department is speculation.

An announced date is a public commitment, not evidence that production considered it easy. Production is often the job of converting uncertain creative work into decisions that can survive such commitments.

## Who is responsible for quality assurance?

Both sides can contribute. A developer may embed QA with feature teams and maintain internal test, automation, build, and compatibility work. A publisher may provide external QA, certification coordination, localisation testing, compliance, compatibility labs, or submission support.

Platform certification does not mean a game is free of every bug; it checks specified platform requirements. Creative quality, balance, accessibility, network stability, and performance still require their own criteria.

Outsourced testers remain part of the development labour story. Credits and responsible reporting should not turn “the studio” into a shorthand that erases partners.

## Read a game credit accurately

Use these sources in order:

1. Full in-game credits.
2. Official store page fields and legal notices.
3. Developer and publisher websites.
4. Official corporate acquisition or partnership announcements.
5. Corporate filings where applicable.
6. Sourced reporting that distinguishes fact from inference.

Look for labels such as **developed by**, **published by**, **co-developed by**, **port by**, **licensed by**, and copyright or trademark ownership. Note that credits can be incomplete, disputed, updated, or governed by company policy.

Do not use logo order as a ranking of labour. Marketing screens optimise recognition and contractual placement, not organisational education.

## Self-publishing moves work; it does not delete it

A self-publishing studio still needs store assets, ratings, localisation decisions, pricing, customer support, tax and accounting, trailers, community communication, platform builds, release management, security, and incident response. It can hire specialists, but it remains responsible for selecting and coordinating them.

Self-publishing may preserve more control and a larger share of net receipts, while increasing capital exposure, workload, capability gaps, and opportunity cost. A publisher may provide scale and funding while taking rights, approvals, recoupment, or a share of revenue. Neither path is universally superior.

The right comparison asks:

- What capability exists internally?
- Which risk can the studio carry?
- What rights are being granted?
- What funding arrives, when, and under which conditions?
- How are costs recouped and receipts reported?
- Who owns customer relationships and platform accounts?
- What happens if milestones, launch, or post-launch plans change?

Those are deal questions, not a generic recommendation. Obtain legal and financial advice for an actual agreement.

## Early Access makes the split visible

In an [Early Access release](/early-access-games-explained/), the developer may run builds and feedback while the publisher coordinates store messaging, pricing, community, support, and roadmap communication. Or the developer may do all of it.

The public should still distinguish current product facts from future plans. A publisher’s marketing reach cannot guarantee completion; a developer’s sincere roadmap cannot turn uncertainty into delivery.

## Use four labels when analysing a release

For any game, write:

> **Built by:** named teams and partners.  
> **Published by:** commercial and distribution entity or entities.  
> **Owned by:** documented corporate and IP owners, with uncertainty noted.  
> **Funded by:** disclosed sources only.

If a field is unknown, say unknown. The gaming business contains enough real complexity without an analyst adding imaginary ownership arrows because the diagram looked lonely.

## Frequently asked questions

**Can a game developer also be the publisher?**

Yes. Self-publishing means the developer or its company takes responsibility for publishing functions such as store setup, marketing, pricing, release operations, support, and compliance, sometimes with specialist contractors. It does not mean every task is performed by one person. The practical question is which entity controls each responsibility and bears its cost and risk.

**Does a publisher own the game developer?**

Sometimes, but not necessarily. A publisher can own an internal studio, hold a minority investment, finance an independent developer under contract, or provide limited services without corporate ownership. The game’s intellectual property can also be owned separately from the studio. Use corporate filings, official announcements, credits, and reliable reporting rather than treating a publishing credit as proof of acquisition.

**Who owns a video game’s intellectual property?**

The relevant contracts and law decide. A developer may own the IP and license publishing rights, a publisher or platform may own it, an employee-created work may belong to the employer, or several entities may control different rights. Credits do not settle ownership. For a real deal or dispute, review the written agreement with qualified counsel in the relevant jurisdiction.

**What does a video game publisher pay for?**

Depending on the deal, a publisher may fund some or all development, marketing, localisation, testing, certification, manufacturing, distribution, or post-launch support. It may instead provide selected services. Terms can include advances, milestone payments, recoupment, revenue shares, minimum guarantees, or ownership rights, but no one structure applies to every game. Public summaries rarely reveal the full economics.

**Who decides a game’s release date?**

Decision rights vary. Studio leadership, publisher production, platform requirements, retail logistics, financing, marketing, and contractual milestones can all influence timing. A public date is a commitment made by identified parties, not proof that one department dictated it. Delays may reflect quality, scope, certification, dependencies, strategy, or several causes; without evidence, assigning one motive is speculation.

**How can I tell who made a game?**

Read the full credits and official store page, then distinguish development, co-development, porting, outsourcing, publishing, platform, and IP notices. Multiple studios may contribute art, engineering, cinematics, localisation, QA, accessibility, or a specific version. A trailer’s final logo card is marketing shorthand; it is not a complete labour record or corporate diagram.


---

# Game Development Stages: From Pitch to Live Support

> A useful game-development map has six overlapping stages: concept, pre-production, production, validation and quality assurance, launch preparation and release, then post-launch support or live operations. Teams revisit earlier decisions throughout; the labels are management tools, not universal gates. Each stage should have an owner, evidence, budget, risks, and an exit decision. A prototype proves a question, a vertical slice demonstrates a representative quality bar, and content-complete or release-candidate labels require each studio to define them explicitly.

Source: https://gamingindustry247.com/game-development-stages/  
Publisher: Playable Business  
Published: 2026-07-19  
Updated: 2026-08-25

## Use six overlapping stages, each with an exit decision

A useful game-development map has six stages: concept; pre-production; production; validation and quality assurance; launch preparation and release; then post-launch support or live operations. Teams revisit earlier decisions throughout. The labels are management tools, not universal gates: every studio must define the owner, evidence, budget, risks, and decision that make a stage meaningful.

A prototype answers a focused question. A vertical slice demonstrates representative systems and a quality bar. “Alpha,” “beta,” “content complete,” and “release candidate” mean only what a team’s written criteria say they mean. Milestone vocabulary without criteria is office-themed fantasy.

## The six-stage map

| Stage | Core question | Useful evidence | Exit decision |
|---|---|---|---|
| Concept | Is there a coherent opportunity worth testing? | pitch, audience hypothesis, core loop, constraints | fund exploration or stop |
| Pre-production | Can this team build the scoped game? | prototypes, vertical slice, plan, risks, budget | enter larger production, revise, or stop |
| Production | Can the team create integrated content and systems predictably? | playable builds, throughput, burn, defect and risk trends | reach defined completeness |
| Validation and QA | Does the game meet release criteria across users and platforms? | tests, research, performance, compliance, accessibility | approve candidate or return work |
| Launch preparation | Can this build and organisation release and support safely? | certified builds, stores, operations, support, rollback | release, delay, or limit scope |
| Post-launch | Can the game be maintained against its promises? | incidents, stability, feedback, costs, service measures | patch, expand, sustain, or sunset |

The table looks linear because tables have a rectangle problem. Actual teams overlap stages, test continuously, and run different features at different maturity levels.

## Stage 1: concept turns an idea into a testable opportunity

Concept work defines enough of the game to decide whether exploration deserves time and money. Typical questions include:

- Who is the intended player and what problem or desire does the game serve?
- What is the core repeated activity?
- What makes the experience distinct enough to explain?
- Which platforms, controls, business model, and constraints matter?
- Which assumptions could kill the project?
- What is the smallest prototype that tests the largest uncertainty?

Outputs may include a pitch, playable experiment, market and audience research, creative pillars, reference art, technical spikes, and an early business case. None proves demand or commercial success.

The strongest concept documents state uncertainty. “Players will love this” is an aspiration. “We will test whether target players understand and repeat this mechanic without instruction” is a question with evidence attached.

## Prototypes are disposable questions

A prototype may test movement, combat, camera, network architecture, procedural generation, controls, performance, or emotional tone. It can use temporary art and rough code because its purpose is learning.

Prototype quality should match the question. A grey-box level can test navigation but not final visual appeal. A polished combat room may test feel but not production throughput. Presenting one as proof of the other is how optimism quietly becomes a budget line.

Teams should record:

- question;
- test build and conditions;
- participant or technical context;
- observation;
- decision;
- what remains unknown.

The exit from concept can be funding pre-production, another bounded test, a pivot, or cancellation. Stopping weak work early is a production outcome, not an absence of work.

## Stage 2: pre-production tests the whole plan

Pre-production connects creative direction, technical architecture, tools, scope, team, budget, schedule, platform needs, and business model. It reduces the expensive unknowns before content production expands.

Common work includes:

- defining design pillars and core systems;
- selecting or building technology;
- establishing art and audio direction;
- testing pipelines and build automation;
- planning accessibility and localisation;
- identifying platform certification requirements;
- mapping staffing, partners, licences, and dependencies;
- estimating content quantities and production rate;
- creating a risk register and decision cadence.

The [developer and publisher relationship](/game-developer-vs-publisher/) affects who approves milestones, funds work, operates platform accounts, and owns deliverables. Put those responsibilities in writing.

## A vertical slice demonstrates integration, not the whole game

A vertical slice is a representative playable segment intended to show several disciplines and systems working together near a target quality bar. It might include one level, encounter, quest, match, or loop.

Its value lies in integration: design, code, art, audio, interface, performance, tools, build, and production cooperate. But the slice can receive unusual focus and senior attention. It does not automatically prove the remaining content can be produced at the same cost or speed.

Define what the slice validates:

- player experience and visual target;
- pipeline from source assets to build;
- system interactions;
- platform performance;
- team communication;
- approximate content effort.

Also list what it does **not** validate, such as network scale, localisation breadth, progression depth, full accessibility, or months of live operation.

## Stage 3: production scales systems and content

Production turns proven or sufficiently understood foundations into the planned game. Teams build features, levels, quests, assets, audio, interface, narrative, tools, services, and platform versions while continuously integrating them.

Management focuses on flow and risk:

- Are builds usable every day or week?
- Are dependencies visible?
- Is content throughput near the planning assumption?
- Is rework increasing?
- Are performance and memory budgets holding?
- Are outsourced deliveries integrated and credited?
- Are accessibility, localisation, QA, and security involved early?
- Which scope can be cut without breaking the core?

“More people” does not linearly produce “more game.” Onboarding, communication paths, tools, review, and dependency load grow too. No responsible general article can supply one productivity figure for all teams.

## Milestones need definitions and evidence

Studios use first playable, alpha, beta, content complete, feature complete, code complete, release candidate, gold, and other labels differently. Replace assumptions with criteria.

A milestone definition might state:

- included systems and content;
- excluded or deferred work;
- build identifier and branch;
- platform coverage;
- severity thresholds for known defects;
- performance budgets;
- localisation and accessibility state;
- save compatibility;
- sign-off owners;
- next gate.

“Content complete” may mean planned launch content exists, not that it is final, optimised, certified, localised, or bug-free. A label cannot carry more certainty than the checklist beneath it.

## Stage 4: validation and QA run throughout, then intensify

Quality assurance is not a room the build visits after production. Requirements review, automated tests, code review, asset validation, build checks, playtests, user research, compatibility, accessibility evaluation, localisation QA, security testing, and performance profiling should begin earlier.

Late-stage validation broadens because integrated systems reveal interactions:

- functional and regression testing;
- platform compliance and certification preparation;
- hardware and operating-system compatibility;
- network load, failure, and recovery;
- save, migration, and patch testing;
- performance, memory, thermals, and battery where relevant;
- accessibility settings and task completion;
- localisation layout, text, audio, and cultural review;
- moderation, reporting, parental, privacy, and purchase flows.

Testing finds information; leadership decides risk. “QA approved it” should not become shorthand that transfers release accountability away from the people authorised to accept known defects.

## User research and public testing answer different questions

Moderated research can observe comprehension, emotion, controls, onboarding, or accessibility with selected participants. Closed or open tests can expose scale, hardware variety, balance, server behaviour, and community dynamics.

Participants are not automatically representative of the full market. Self-selection, recruitment, incentives, platform, geography, and skill shape feedback. Combine qualitative observation, telemetry collected with appropriate disclosure, defect data, support themes, and business constraints.

One popular post can identify a real problem without measuring its prevalence. One dashboard can measure behaviour without explaining why it happened.

## Stage 5: launch preparation is an operational release

Launching involves more than uploading a build. Teams coordinate:

- platform submission and certification;
- store page, pricing, ratings, legal text, and entitlements;
- localisation and territory availability;
- day-one patch and rollback plans;
- server capacity, monitoring, and incident response;
- customer support and known-issue documentation;
- community moderation and escalation;
- marketing assets and embargoes;
- review access and creator programmes;
- finance, tax, fraud, and refund operations;
- staff coverage and wellbeing.

A go/no-go review should include current build evidence, open risks, owner availability, rollback or containment, and the consequences of delay. Marketing spend already committed is a constraint, not proof that the build is ready.

The chosen [revenue model](/video-game-revenue-models/) expands the checklist. In-app purchases need entitlement, receipt, restoration, fraud, regional, and support testing; subscriptions add renewal and cancellation states.

## Release is a transition, not the end

At launch, real players create combinations no test matrix fully captured. Monitor crashes, performance, servers, queues, payments, support, reviews, exploits, abuse, accessibility barriers, and data integrity.

Triage distinguishes:

- safety, security, privacy, or data-loss incidents;
- crashes and blockers;
- severe progression or economy exploits;
- degraded service;
- quality defects;
- feature requests and balance preferences.

Communicate what is known, what is being investigated, and when the next update will arrive. Avoid a confident root-cause story before evidence exists.

## Stage 6: post-launch support or live operations

A finite offline game may receive patches, compatibility updates, localisation, DLC, or a final supported state. A live game adds server operations, ongoing content, economy management, security, moderation, anti-cheat, customer support, community, and an eventual service-ending plan.

The stage needs budgets and owners for:

- incident response and on-call work;
- patch cadence and platform submission;
- content creation and validation;
- save and account migration;
- vulnerability response;
- community standards and appeals;
- vendor and infrastructure contracts;
- archival, shutdown, refunds, or offline plans where relevant.

An [Early Access release](/early-access-games-explained/) overlaps production and public operation sooner. That makes feedback and expectation management production systems, not side-channel marketing.

## Run a review at every gate

Use the same six prompts:

1. What did we intend to learn or deliver?
2. What evidence exists in this identified build?
3. Which risks changed?
4. Which assumptions failed?
5. What work, money, people, and time does the next stage require?
6. Is the decision proceed, revise, reduce, pause, or stop?

Record dissent and conditions. A green status produced by deleting every yellow row is not project health; it is spreadsheet gardening.

The stages work when they improve decisions. Concept narrows the question, pre-production tests feasibility, production creates the game, validation tests the promises, launch releases an organisation as well as a build, and post-launch proves whether that organisation can keep them.

## Frequently asked questions

**What happens during game pre-production?**

Teams clarify the audience, core loop, scope, technical approach, art direction, production plan, risks, staffing, budget, and platform needs. They may build prototypes and a vertical slice to test different questions. Good pre-production reduces uncertainty; it does not guarantee the plan survives production. Exit criteria should state what evidence justifies larger spending and what remains unresolved.

**What is a vertical slice in game development?**

A vertical slice is a representative playable segment intended to demonstrate how several disciplines and systems work together at a target or near-target quality bar. Its exact scope varies. It is not automatically production-ready architecture, a public demo, or proof that all content can be produced at the same cost. Teams should state which risks the slice actually tests.

**When does quality assurance start in game development?**

Quality work should begin before the formal test phase. Requirements, prototypes, tools, builds, automation, and feature reviews all create opportunities to prevent defects. Dedicated QA activity typically expands as systems and content integrate. Testing near release cannot compensate cheaply for every architectural, scope, accessibility, localisation, performance, or usability problem discovered late.

**What does content complete mean?**

It usually means the planned release content has been implemented to a defined threshold, but studios use the label differently. It does not necessarily mean bug-free, fully optimised, certified, localised, or ready to ship. A useful milestone includes written inclusion criteria, known exceptions, build identification, owners, and the remaining work needed for the next gate.

**What happens after a game launches?**

Teams monitor stability, crashes, servers, support, reviews, accessibility issues, exploits, economy behaviour, and player feedback; ship patches; maintain platform compliance; and decide on content or service changes. A finite offline game still needs support planning. A live service adds ongoing operations, moderation, security, hosting, analytics, content cadence, and an eventual end-of-service responsibility.

**Is every game-development pipeline the same?**

No. Team size, genre, technology, financing, platform, external partners, regulation, release model, and organisational culture change the pipeline. A solo mobile game and a multi-studio console release cannot share one literal workflow. The transferable practice is to define terms, dependencies, evidence, decision owners, and risk—not copy stage names while leaving their meaning blank.


---

# How Video Games Get Funded Before Launch

> Video games are funded through one source or a stack of self-funding, work-for-hire income, publisher advances, crowdfunding, grants or tax incentives, platform deals, private capital, and sales from a playable early release. Each route trades different amounts of ownership, control, time, public obligation, repayment, or revenue. Studios should map committed cash to development stages and model what happens when conditional money or sales do not arrive.

Source: https://gamingindustry247.com/how-video-games-get-funded/  
Publisher: Playable Business  
Published: 2026-09-05  
Updated: 2026-09-07

## Games are usually funded in stages, not by one magic cheque

Video games are funded through some mix of a studio's own money, publisher advances, work-for-hire income, private investment, public grants or tax incentives, platform arrangements, crowdfunding, and sales from a playable release. The route decides more than who pays. It can affect ownership, milestones, creative approval, release timing, platform scope, marketing, and who absorbs a delay.

Most projects use a **funding stack** rather than one source from pitch to launch. A founder may pay for a prototype, a grant may fund vertical-slice work, and a publisher may finance production and launch. The useful question is not “Which route is best?” It is “Which risk are we willing to keep, and which control are we willing to trade?”

This is industry education, not investment, tax, accounting, or legal advice. Deals and public programs vary by company, country, project, and date. Studios should model their own runway and have qualified advisers review binding terms.

## What exactly needs funding before launch?

“Development budget” can hide several different bills:

- salaries, contractor fees, and founder living costs;
- software, hardware, cloud services, and development kits;
- art, audio, writing, localization, accessibility, and quality assurance;
- legal, accounting, insurance, ratings, certification, and company overhead;
- ports, store assets, trailers, community work, public relations, and paid marketing;
- reward fulfillment, taxes, and platform or campaign fees where applicable;
- contingency for rework, delays, failed submissions, and post-launch support.

A prototype budget proves a game idea. A production budget gets the content made. A launch budget gets the build tested, certified, marketed, and shipped. Confusing the three is how a project appears funded right up until the expensive part arrives wearing a platform-certification badge.

Our [game-development stages guide](/game-development-stages/) shows when these costs tend to appear. The funding plan should map cash to those stages, not simply divide one total by the number of months.

## The seven main video-game funding routes

| Route | What supplies cash | What the studio commonly gives or risks | Best question to ask |
|---|---|---|---|
| Self-funding | Savings, salary, prior-game revenue | Personal capital, time, slower pace | What is the hard loss limit? |
| Work for hire | Client pays for contracted delivery | Team capacity and schedule | Does this protect or crowd out the original game? |
| Publisher funding | Advance or milestone payments | Rights, revenue participation, approvals, recoupment | Which obligations survive cancellation? |
| Crowdfunding | Backer pledges tied to a campaign | Public promises, rewards, communication, fulfillment | Does the goal cover the complete promised scope? |
| Grants or incentives | Public or institutional program | Eligibility, reporting, restricted spend, timing | Is cash paid before or after eligible costs? |
| Platform arrangement | Platform holder support or commercial deal | Platform obligations, timing, confidentiality, possible exclusivity | What is guaranteed in writing? |
| Private capital | Equity, debt, convertible or project investment | Ownership, repayment, governance, return expectations | Is the investor funding this game or the company? |
| Early sales | Revenue from a genuinely playable build | Public scrutiny, support load, unfinished-product expectations | Can development continue if sales disappoint? |

The table describes structures, not standard terms. There is no universal publisher split, grant percentage, advance size, or investor demand.

## Self-funding keeps control and concentrates risk

Self-funding can mean savings, a day job, consulting income, earlier-game revenue, or founders working unpaid. It offers a clean decision chain: the studio chooses the scope, partners, schedule, and intellectual-property strategy.

The trade is equally clean. The founders carry the financial risk, and limited cash can lengthen the schedule. A long schedule is not free; it increases the time during which tools, platforms, staff availability, and audience expectations can change.

A responsible self-funded plan names:

1. the cash the founders can lose without endangering rent, debt payments, tax obligations, or emergency savings;
2. the unpaid time each person can actually sustain;
3. the smallest build that tests the core promise;
4. the date and evidence required to fund the next stage; and
5. the stop, pause, or scope-reduction rule.

Control is valuable. So is still having a solvent studio when the build reaches content complete.

## Work for hire can finance a game indirectly

A studio may build features, ports, art, quality assurance, or complete projects for clients, then use the margin to support its own game. This is not outside funding for the original title; it is operating income.

The advantage is that the studio earns rather than sells ownership. The disadvantage is capacity. Client deadlines tend to be real, while the internal game is wonderfully understanding and therefore keeps moving to next month.

Track the two businesses separately. Record client revenue and delivery cost, then state the exact amount of staff time or cash transferred to the original project. Check employment, contractor, confidentiality, and intellectual-property terms so client work does not create a dispute over tools or code later.

## Publisher funding exchanges risk for negotiated rights

WIPO's 2024 game-industry analysis describes the familiar division: developers create games, while publishers may finance and promote them. WIPO's *Mastering the Game* also notes that publishers can contribute distribution reach, marketing expertise, porting support, data, and other release services.

In a funded deal, payments are often attached to milestones or deliverables. The publisher may recoup specified costs from game revenue before the developer receives some or all of its revenue share. Ownership, licenses, sequel rights, platforms, territories, approval rights, marketing commitments, reporting, audit access, warranties, cancellation, and post-termination rights all depend on the contract.

Do not reduce the deal to “advance plus royalty.” Make a rights-and-cash map:

| Question | What the written agreement must clarify |
|---|---|
| What is funded? | Development, porting, localization, marketing, support, or a defined mix |
| When is it paid? | Signing, milestone acceptance, calendar dates, or reimbursement |
| What is recouped? | Which costs, in what order, from which revenue base |
| Who owns what? | Game IP, code, tools, trademarks, ports, sequels, and derivative rights |
| Who decides? | Scope, release date, platforms, price, marketing, and changes |
| What if it ends? | Cure periods, termination, completed work, repayment, and rights reversion |

Our [developer-versus-publisher guide](/game-developer-vs-publisher/) separates the companies' broader roles. A lawyer familiar with games contracts should review the actual deal.

## Crowdfunding sells a promise before it sells a finished game

Reward-based crowdfunding can finance a defined stage while building an audience. It can also turn design ideas, delivery estimates, physical rewards, and community updates into public commitments.

Kickstarter's current rules are specific: funding is **all-or-nothing**, the goal should cover what is needed to complete the project plus relevant campaign costs, and a funded creator is responsible for completing the promised work and fulfilling rewards to the best of their ability. Kickstarter also tells backers that it is not a store.

A campaign budget therefore needs more than game production. Include campaign assets, payment uncertainty, taxes, reward manufacturing, packing, shipping, customer support, failed deliveries, and update work. If the project only works when the campaign clears far more than its stated goal, the goal does not describe the promised project.

Backers are not automatically shareholders, publishers, or design directors. The campaign's terms and reward structure define what they receive. Keep stretch goals subordinate to the schedule and capacity that already exist.

## Grants and tax incentives have eligibility, timing, and evidence rules

Public money can take several forms: competitive grants, cultural or innovation funds, prototypes or content programs, regional production incentives, and tax credits. These are not interchangeable.

The UK Games Fund illustrates the grant route: its public evaluation describes support intended to help early-stage games businesses and pathways toward later publisher or private investment. The United Kingdom also operates a Video Games Expenditure Credit with separate eligibility and tax rules. Another country or region will use different definitions.

Before adding public support to runway, verify:

- whether the applicant, company, project, people, and location qualify;
- which costs and dates are eligible;
- whether funding is an advance, reimbursement, credit, loan, or matched contribution;
- reporting, audit, credit, cultural, hiring, or residency conditions;
- whether other public or private money changes eligibility; and
- when cash can realistically reach the bank.

An award headline is not a cash-flow schedule. Confirm current program documents and get local tax or legal advice before relying on it.

## Platform funding is a contract category, not free visibility

A platform holder may fund development, porting, subscription inclusion, timed availability, marketing participation, or another commercial objective. The exact deal may be confidential, which is why outside observers should avoid turning one announcement into an industry-standard term sheet.

For the studio, separate three things:

1. **cash or guaranteed consideration** written into the agreement;
2. **services or placement** defined with measurable obligations; and
3. **possibilities**, such as featuring or future support, that are not guaranteed.

Then model the constraint: platform delivery work, certification, release timing, technical requirements, reporting, marketing approvals, and any exclusivity. A deal can reduce funding risk while increasing concentration risk.

## Private investment funds a return, not merely a launch

Equity investors buy an ownership interest in a company. Lenders expect repayment under agreed terms. Convertible instruments can begin as one form and convert under specified events. Project finance may attach returns to a particular title or revenue stream.

These structures have different consequences for control, future fundraising, security, repayment, governance, and failure. A studio seeking capital should be able to explain whether it is building one game, a repeatable studio, technology, an intellectual-property portfolio, or some combination. The investor will price a different proposition in each case.

Do not describe private money as proof that a game will sell. It proves that someone agreed to finance under particular terms. Verify the investor, source of funds, authority, documentation, and conflicts; use qualified legal and financial advice.

## Early Access is a sales model, not a rescue plan

Selling a playable build can generate revenue before a final release and create a feedback loop. It also creates customers, support work, reviews, refunds under applicable rules, community expectations, and an operating live product.

Steam's current Early Access documentation is unusually blunt: Early Access is **not a way to crowdfund development** and should not be used solely to fund completion. A title must offer a playable build worth its current price, and the studio should be prepared for the possibility that sales are not enough to finish it.

That makes early sales a potential part of a funding stack, not reliable missing-budget arithmetic. Before launch, model a low-sales case, update workload, save compatibility, support coverage, and the cost of developing in public. The [Early Access explainer](/early-access-games-explained/) covers the player and studio expectations in depth.

## Funding route and revenue model are different decisions

Funding answers who pays **before or during production**. A revenue model answers how the released game earns money. Premium purchase, downloadable content, subscriptions, advertising, cosmetics, and other models do not identify who financed development.

A publisher-funded game can be premium or free-to-play. A self-funded game can enter a subscription catalog. A crowdfunded game can later sell expansions. Keep the capital plan and the [video-game revenue model](/video-game-revenue-models/) on separate pages of the spreadsheet, then connect them through realistic launch and operating assumptions.

## Use a stage-gate funding map

Build the plan from evidence, not optimism:

| Stage | Evidence required before more spending | Funding question |
|---|---|---|
| Concept | Clear audience, core promise, feasibility risks | What is the cheapest honest test? |
| Prototype | Playable core interaction and technical findings | Is there enough signal to fund a vertical slice? |
| Vertical slice | Representative quality, budget and production plan | Which partner can evaluate the real proposition? |
| Production | Milestones, staffing plan, tracked burn and scope control | Is committed cash sufficient to the next decision gate? |
| Launch preparation | Stable build, platform path, QA and marketing assets | Who pays for certification, launch and contingency? |
| Post-launch | Support plan and measured demand | What work is funded even if sales start slowly? |

At each gate, show committed cash, conditional cash, monthly obligations, unpaid founder labor, liabilities, and remaining contingency. Do not put a possible grant, unsigned publishing conversation, hoped-for platform feature, or forecast sale into the committed column.

## The five questions every funding plan must answer

1. **Runway:** When does committed cash run out under the base and delayed schedule?
2. **Rights:** Who owns, licenses, approves, or can restrict the game and its future uses?
3. **Obligations:** What milestones, rewards, reports, repayments, services, or release terms are owed?
4. **Failure:** What happens if a milestone is rejected, a campaign underperforms, a grant is delayed, or sales are weak?
5. **Next gate:** Which observable result earns the next round of spending?

The cleanest funding plan is not the one with the fewest sources. It is the one where every source has a defined stage, cost, condition, trade, and failure case. A game can survive a complicated capital stack. It cannot survive a stack of assumptions wearing little dollar-sign hats.

## Sources checked

- [WIPO World Intellectual Property Report 2024: video-game hubs](https://www.wipo.int/web-publications/world-intellectual-property-report-2024/en/5-leveraging-local-know-how-to-develop-video-game-hubs.html)
- [WIPO: Mastering the Game](https://tind.wipo.int/nanna/record/45851/files/wipo-pub-2022-en-mastering-the-game.pdf?registerDownload=1&version=1&withMetadata=0&withWatermark=0)
- [Kickstarter: setting a funding goal](https://help.kickstarter.com/hc/en-us/articles/115005134293-How-to-set-the-right-funding-goal-for-your-Kickstarter-campaign)
- [Kickstarter: creator obligations after funding](https://help.kickstarter.com/hc/en-us/articles/115005028834-What-is-a-creator-obligated-to-do-once-their-project-is-funded)
- [Steamworks: Early Access](https://partner.steamgames.com/doc/store/earlyaccess)
- [UK Games Fund evaluation](https://www.gov.uk/government/publications/evaluation-of-the-uk-games-fund-final-report/evaluation-of-the-uk-games-fund-final-report)

## Frequently asked questions

**Who pays for video game development before launch?**

Founders, clients, publishers, backers, public programs, platform holders, investors, lenders, and customers buying a playable early release can all contribute. Large studios may finance projects internally; independent teams often combine routes. The important distinction is whether money is committed, conditional, reimbursed later, repayable, or exchanged for rights, revenue, ownership, services, or delivery obligations.

**How do publishers fund video games?**

A publisher may pay an advance or milestone-based development funding and may also support marketing, distribution, porting, localization, quality assurance, or launch. The agreement defines recoupment, revenue participation, intellectual-property rights, approvals, platforms, territories, cancellation, and reporting. There is no universal publisher deal, so studios need qualified legal review of the actual contract.

**Can an indie game be fully self-funded?**

Yes. Developers may use savings, salary from another job, consulting income, or revenue from earlier work. Self-funding can preserve control but concentrates financial and schedule risk. A responsible plan sets a loss limit, protects personal essentials, funds the smallest useful proof first, records unpaid labor, and defines when to pause, reduce scope, or seek outside money.

**Is crowdfunding the same as selling a game early?**

No. Reward crowdfunding collects pledges for a promised creative project under the platform's terms; Kickstarter states that it is not a store. Early Access sells a playable unfinished build to customers. Steam explicitly says its Early Access program is not a way to crowdfund development and should not be used solely to finance completion.

**Are video-game grants free money?**

A grant may avoid equity or commercial recoupment, but it usually carries eligibility, application, permitted-cost, reporting, timing, evidence, and audit conditions. Tax incentives and expenditure credits are different again and may arrive after qualifying spend. Studios should verify current program documents and model when cash is available, using local tax, accounting, and legal advice.

**What is the safest way to compare game funding options?**

Compare each route across runway, rights, obligations, failure conditions, and the next evidence gate. Separate committed cash from unsigned conversations, possible grants, hoped-for platform support, and forecast sales. Then map payments and costs to concept, prototype, vertical slice, production, launch, and support stages. The best fit depends on which risks and control the studio can retain.


---

# Publisher Funding Deals: Advances, Recoupment and Rights

> A publisher deal defines what a publisher funds or provides, what the developer must deliver, which rights each side controls, and how receipts are divided. Development payments may depend on accepted milestones; later royalties may be reduced by contractual recoupment. Funding does not automatically transfer game ownership, and a percentage alone cannot describe the economics. Use the current complete agreement, with qualified games-contract legal and financial advice for a real decision.

Source: https://gamingindustry247.com/publisher-funding-deals-explained/  
Publisher: Playable Business  
Published: 2026-09-08  
Updated: 2026-09-08

## How do publisher deals work for game developers?

A publisher deal defines what a publisher funds or provides, what the developer must deliver, which rights each side controls, and how receipts are divided. Development payments may depend on accepted milestones; later royalties may be reduced by contractual recoupment. Funding does not automatically transfer game ownership, and a percentage alone cannot describe the economics. Use the current complete agreement, with qualified games-contract legal and financial advice for a real decision.

## What does the publisher actually pay for?

Separate cash paid to the studio from services supplied for the release. A development advance can fund production, while localization, quality assurance, marketing or porting may be separate responsibilities. “Publishing support” needs a defined scope.

Raw Fury's public developer-resources page illustrates why that distinction matters. Its description, explicitly written in December 2020, separates internally supplied work from externally invoiced services when discussing recoupable costs. That is a dated account of one publisher's approach, not a current offer to every studio or a market rule. The page also warns that its contract does not describe the full support relationship. [Raw Fury's public explanation](https://rawfury.com/developer-resources/)

For a proposed arrangement, make an original three-column record: **cash to studio**, **publisher-provided work**, and **external work charged to the project**. Put each promised item in the appropriate column and add its contract reference. An unallocated responsibility remains a question; do not convert a sales conversation into a funded commitment.

## When does milestone funding become payable?

An advance is development funding paid before later sales-based participation, under the agreement's conditions. It need not arrive as one payment.

Deviant Legal's January 2026 milestone guide describes schedules connecting deliverables, review and installments. Its key distinction is between delivering a build and having that build accepted. The label “beta” alone does not resolve what must work, who reviews it or what happens after rejection. [Milestone and advance guidance](https://deviantlegal.com/guide/game-developers-guide-publishing-agreements/milestone-schedules-advance-payments/)

For each payment, locate the deliverable, acceptance criteria, review period, rejection process and payment trigger. Do not assume silence means approval. Ask how revised scope changes the schedule and who bears the resulting cost.

An original record might say: “Build submitted; review pending; invoice trigger unresolved.” It must not say “cash received.” Those are separate events even if a presentation combines them in one milestone box.

## What does recoupment mean?

Recoupment means recovering specified spending through the contract's revenue calculation. It is separate from the advance payment already made to fund development.

Wiggin's publishing guide explains that a percentage must be read alongside the definition of gross or net revenue, permitted deductions, and where development funding is recovered: from the wider receipts or from the developer's allocated share. The position in the calculation matters. [Wiggin's financial-terms guide](https://www.wiggin.co.uk/app/uploads/2025/11/Wig-Indies-A-Developers-Guide-to-Negotiating-Publishing-Deals.pdf)

Find the exact recoupable items and any approval limits or caps. Then identify the order of deductions and distribution. A marketing expense must not appear twice merely because one worksheet calls it a deduction and another calls it a recoverable cost.

Our [revenue-model guide](/video-game-revenue-models/) explains why player spending, receipts and profit are different quantities. None supplies the missing definitions in an undisclosed agreement.

## Can the same percentage produce different results?

Yes. Here is an entirely fictional arithmetic exercise, not a real offer, industry norm, forecast or recommendation.

Assume a reporting period begins with **$100,000 of defined receipts** after all upstream deductions. Assume **$40,000 of previously paid funding remains unrecouped**. There are no additional costs, reserves, taxes or adjustments in this simplified exercise. The developer allocation is **60%**, with the publisher allocated **40%** after the stated calculation.

| Calculation | Model A: recover before splitting | Model B: recover from developer allocation |
|---|---:|---:|
| Starting receipts | $100,000 | $100,000 |
| Funding recovered before split | $40,000 | $0 |
| Amount divided 60% / 40% | $60,000 | $100,000 |
| Developer allocation before its recoupment | $36,000 | $60,000 |
| Recovery from developer allocation | $0 | $40,000 |
| Additional cash to developer | $36,000 | $20,000 |
| Total cash retained by publisher | $64,000 | $80,000 |
| Remaining unrecouped funding | $0 | $0 |

In Model A, $100,000 minus $40,000 leaves $60,000. The developer receives 60% of that, or $36,000; the publisher retains the $40,000 recovery plus $24,000.

In Model B, the developer's initial allocation is $60,000. Recovering $40,000 from that allocation leaves $20,000 payable. The publisher retains its $40,000 allocation plus $40,000 recovery.

Both columns distribute exactly $100,000. Neither counts the earlier advance as new cash in this reporting period. The developer-cash difference is $16,000 despite the same headline percentage.

If only $30,000 of receipts existed, both models would produce no additional developer cash under these assumptions. Model A would leave $10,000 unrecouped; Model B would leave $22,000, because only the developer's $18,000 allocation reduces that balance. A low-receipt case reveals differences the first example hides.

This is a calculation demonstration, not profit accounting or a prediction of personal repayment liability.

## Does the publisher own the game?

Read ownership and licensed permissions separately. WIPO distinguishes an assignment, which transfers ownership, from a license granting permission under specified terms. Its general technology-transfer guidance is useful vocabulary, not a game-specific ruling. [WIPO on licensing and assignment](https://www.wipo.int/en/web/technology-transfer/agreements)

A concrete historical example: Epic's March 26, 2020 publishing announcement said developers would retain 100% of intellectual property and creative control; it described funding up to 100% of development costs and developers receiving at least 50% of profits after costs were recouped. Those are the announcement's terms, not a universal split, a complete contract or a guarantee of today's availability. [Epic's announcement](https://store.epicgames.com/en-US/news/epic-games-publishing-announcement)

For a current document, record the game, platforms, territory, duration, exclusivity and future works covered. Retaining ownership does not by itself answer what someone else is licensed to do.

## What should a royalty report let you trace?

Start with the reporting period, receipts, deductions, recovery balance and resulting payment. Compare the opening balance with the previous statement, then identify additions and amounts recovered. A payment should be explainable through the agreed calculation.

Deviant Legal's audit guide distinguishes a platform sales report from access to the publisher's deduction records. A contractual audit provision can permit an independent professional to examine the relevant books; its conditions matter. [Audit-clause guidance](https://deviantlegal.com/guide/game-developers-guide-publishing-agreements/audit-clause/)

Ask who may examine records, what notice is required, which periods are covered and who pays. Do not infer an automatic right, reimbursement threshold or unlimited access from a general explainer. Have an accountant and lawyer assess the actual reporting and audit provisions.

## What happens if the relationship ends?

Termination rights and termination consequences answer different questions: when an agreement can end, and what remains afterward.

Deviant Legal's January 2026 discussion identifies continuing payments, licenses, store pages, assets and unrecouped funding as connected issues. Its examples are not default law. [Termination guidance](https://deviantlegal.com/guide/game-developers-guide-publishing-agreements/consequences-of-termination/)

Ask qualified counsel to distinguish expiry, alleged breach and other termination grounds. Establish whether any repayment is triggered, who can continue distributing, and which cooperation is required for a transition. Do not assume an unrecouped balance is always personally repayable, always forgiven or proof that rights revert automatically.

## What is a useful final reading check?

This original document index keeps unresolved questions visible:

- **Funding schedule:** what arrives, subject to which event?
- **Cost definition:** what enters the recovery balance?
- **Calculation:** where is each deduction taken?
- **Rights schedule:** what is owned and what is licensed?
- **Reporting clause:** how are figures checked?
- **Exit provisions:** what survives and who must act?

Attach a document version, clause reference and unanswered question to each entry. Our [industry basics section](/industry-basics/) supplies wider organizational context. The index helps prepare a professional discussion; it does not establish enforceability or whether a deal is suitable.

## Sources

- [Raw Fury: Developer Resources](https://rawfury.com/developer-resources/).
- [Deviant Legal: Milestone schedules and advance payments](https://deviantlegal.com/guide/game-developers-guide-publishing-agreements/milestone-schedules-advance-payments/).
- [Wiggin: A developer's guide to negotiating publishing deals](https://www.wiggin.co.uk/app/uploads/2025/11/Wig-Indies-A-Developers-Guide-to-Negotiating-Publishing-Deals.pdf).
- [WIPO: Technology Transfer Agreements](https://www.wipo.int/en/web/technology-transfer/agreements).
- [Epic Games: March 26, 2020 publishing announcement](https://store.epicgames.com/en-US/news/epic-games-publishing-announcement).
- [Deviant Legal: Audit clause](https://deviantlegal.com/guide/game-developers-guide-publishing-agreements/audit-clause/).
- [Deviant Legal: Consequences of termination](https://deviantlegal.com/guide/game-developers-guide-publishing-agreements/consequences-of-termination/).

## Frequently asked questions

**Does signing a publisher deal mean all funding arrives immediately?**

Not necessarily. A deal may connect payments to signing, accepted deliverables or other stated events. Identify the payment trigger, review procedure and what happens after rejection or delayed feedback. A submitted build is not automatically an accepted milestone or received cash. Have qualified advisers check the actual schedule and contractual conditions.

**What is publisher recoupment?**

Recoupment is recovery of specified spending through the agreement's revenue calculation. Read which costs qualify, where recovery happens and what receipts or allocated share it uses. It is distinct from an advance already paid for development. A percentage without these definitions cannot establish the studio's payment; use legal and accounting review for a real deal.

**Does a publisher automatically own the game's intellectual property?**

No ownership conclusion follows from the publisher credit alone. A license permits specified uses while an assignment transfers ownership; the actual rights, scope and applicable law must be examined. Record platforms, territory, duration, exclusivity and future works separately. Qualified counsel should review the complete agreement rather than relying on a public announcement.

**Do developers have to repay unrecouped funding if a game sells poorly?**

Do not infer personal repayment from an unrecouped balance alone. Recoupment from receipts and a separate obligation to return money are different matters. Termination grounds, breach provisions and other written conditions can change obligations. Have qualified counsel assess the complete agreement and applicable law; neither automatic forgiveness nor automatic personal liability is a safe assumption.

**Why might a store sales report be insufficient to check royalties?**

A platform report may not show all publisher deductions, recoverable costs or balances used in the contractual calculation. Request the agreed royalty reporting and identify how its figures can be examined. Audit scope, notice, professional requirements and cost allocation depend on the contract. An independent accountant and qualified lawyer can assess the relevant provisions.


---

# Self-Funding an Indie Game: Cash and Capacity Planning

> Start with a bounded project you can support using your own resources, then track cash availability and working time separately. Day-job income, contract receipts and savings each need different checks; none makes development free. Set a personal loss limit, protect essential obligations and test what happens if expected money arrives late. This is general planning education, not personal financial advice; use qualified financial, accounting and legal advisers for consequential decisions.

Source: https://gamingindustry247.com/self-funded-indie-game-studio/  
Publisher: Playable Business  
Published: 2026-09-09  
Updated: 2026-09-09

## How can you fund your own indie game?

Start with a bounded project you can support using your own resources, then track cash availability and working time separately. Day-job income, contract receipts and savings each need different checks; none makes development free. Set a personal loss limit, protect essential obligations and test what happens if expected money arrives late. This is general planning education, not personal financial advice; use qualified financial, accounting and legal advisers for consequential decisions.

The aim is to fund the next useful piece of evidence, not to declare an entire dream game affordable because its first prototype runs. Our broader [game-funding guide](/how-video-games-get-funded/) compares funding routes. Here we build the working plan for the route where you carry the risk.

## What does self-funding actually mean?

The [US Small Business Administration's planning guide](https://www.sba.gov/counseling/plan-your-business/) describes self-funding, or bootstrapping, as using your own financial resources. It pairs retained control with personal risk and warns against spending more than you can afford.

For a game project, distinguish three proposed contributions:

- Money already available for the project after personal and business obligations have been considered.
- Future contributions from employment income, dependent on that income continuing and remaining affordable.
- Proceeds from client work, dependent on completing the work and receiving payment.

This is our planning classification, not a claim that every studio is funded this way. Record each contribution's owner, amount, expected date and conditions. Do not quietly relabel a hoped-for payment as money already available.

Self-funding also does not decide who owns employer-related code, contractor deliverables or licensed assets. Have a qualified lawyer review applicable agreements before relying on those rights. This article is not permission to reuse a client's work or an employer's resources.

## What should the cash plan contain?

The SBA recommends separating one-time startup costs from recurring monthly expenses. Use that distinction as a starting point, then obtain actual quotes, current licence terms and your own payment schedules.

Our suggested game-specific cost headings are:

| Cost heading | What to record |
|---|---|
| Tools and equipment | Purchase or subscription terms, renewal date and project allocation |
| Commissioned work | Defined deliverable, acceptance process and payment dates |
| Testing and release preparation | Required work, responsible person and quote or estimate |
| Ongoing operation | Services and support the proposed release actually needs |
| Professional advice and administration | Agreed work, fees and applicable obligations |
| Ending or pausing the project | Unpaid commitments and services that continue until cancelled |

Not every project incurs every item. Mark an inapplicable heading as such; do not fill empty cells with invented industry averages.

For each item, distinguish an estimate from an accepted quote or binding commitment. Record the currency and whether the figure includes relevant taxes. Ask your accountant how to handle transfers, tax treatment and obligations in your jurisdiction rather than borrowing a rule from another country.

## Why is an invoice not the same as cash received?

An invoice records a request for payment; your planning question is when the money will actually be available. A completed client milestone may still need acceptance and payment processing under its agreement.

[Australian government cash-flow guidance](https://business.gov.au/finance/cash-flow/set-up-a-cash-flow-statement) tells you to label estimated figures clearly and asks when money enters and leaves the business. Its closing-balance calculation is:

**opening balance + cash received − cash paid = closing balance**

For a forecast, label the incoming and outgoing figures as estimates. Carry each period's closing balance into the next period's opening balance. Keep actual results beside the forecast rather than overwriting the original expectation.

Our additional check is to move an expected receipt into a later period while leaving already-committed payment dates unchanged. Ask which obligation becomes unfunded first. A positive total across the whole project can conceal a shortage before the money arrives.

Do not count the same receipt as both client-business cash and a second, independent contribution to the game. Record the transfer between them once in the relevant project view; obtain accounting help for formal records.

## How do you stop counting the same hours twice?

Create a second plan for capacity. Cash can be available while the person needed to use it is fully occupied elsewhere.

Use this original worksheet for each contributor:

1. Identify the period being planned.
2. State the hours realistically available for project work.
3. Assign hours to specific tasks, including administration, integration and testing.
4. Record client commitments separately.
5. Compare the allocation with actual work at the next review.

A fictional example uses hours only, not wages or a recommended working week. A developer has allocated 12 hours to the game during one planning period. Integration and testing need 4, leaving 8 for feature work: 12 − 4 = 8. An additional feature estimated at 11 hours therefore does not fit that remaining allocation.

That example does not prove the feature takes 11 hours. It shows how to spot a conflict in your own estimates. Reduce the task, move its date or revise the plan; do not hide the difference by removing testing from the record.

Our [development-stages guide](/game-development-stages/) explains why a prototype, an integrated slice and a release-ready build answer different questions.

## What changes when client work pays the bills?

Treat client delivery and your game as competing uses of finite capacity. A new commission might improve future cash while reducing the time available to build the game before that cash arrives.

Before accepting work, list the deliverables, review rounds, dependencies and payment conditions from the proposed agreement. Then update both plans. Do not insert the invoice value into the game's budget while leaving the development calendar untouched.

Compare expected receipts with the costs and commitments required to deliver that work. The full invoice is not automatically spare project money. Get professional help where tax, employment status, ownership or contractual exposure is unclear.

A useful review question is specific: “Which game task moves if this client deadline takes priority?” That is more actionable than promising to catch up later.

## Which scope changes deserve a new decision?

Our editorial rule is to review any change that adds work, spending or an ongoing promise. A second platform, online mode or extra content area should arrive with an explanation of its dependencies, not just a new line in the feature list.

Use a change card:

- What player problem does this solve?
- What new implementation, integration and testing work does it require?
- Who will do that work, and when?
- Which quoted or estimated costs change?
- Does it add ongoing support or third-party obligations?
- What is removed, delayed or newly funded to accommodate it?

A rejected change can remain a good idea. The backlog is allowed to contain good ideas that are not in the current game.

Record exclusions in the build plan so a postponed feature does not reappear as an assumed launch promise.

## Can Early Access or a paid playtest fill the gap?

Do not treat an unfinished release as guaranteed missing funding. [Steam's Early Access documentation](https://partner.steamgames.com/doc/store/earlyaccess) says the programme is not a way to crowdfund development, requires a playable product and should not be used solely to fund completion. It explicitly asks developers to consider what happens if expected sales do not arrive.

That is a platform rule and planning warning, not a prediction about your sales. Our [Early Access explainer](/early-access-games-explained/) covers the additional public-development responsibilities.

[Steam Playtest](https://partner.steamgames.com/doc/features/playtest) is a separate free testing feature associated with the main game. Valve prohibits selling access or monetising it through in-game transactions. It can support learning, but it is not a paid funding product.

No participant count, wishlist total or encouraging comment is treated here as guaranteed future revenue.

## When should you pause or seek another funding route?

Set the review before accepting new commitments. Bring the current build, actual cash record, remaining obligations, capacity plan and unresolved questions.

Our suggested decisions are: continue the defined stage, run a smaller test, reduce scope, pause, or investigate outside funding. Record why the evidence supports the choice. Seeking money is not the same as receiving it, so do not spend against an unsigned discussion.

Pause for advice if proceeding depends on money needed for essential obligations, unclear rights, unreviewed borrowing or commitments the team cannot support. No general article can decide whether you should leave a job or risk personal savings.

A useful plan ends with the next review and the evidence needed there. It does not need a dramatic promise about the launch date.

## Sources

SBA guidance supports the general self-funding and expense distinctions. Australian government guidance supports cash-flow timing and arithmetic; it is not presented as local tax advice elsewhere. Valve's current documentation establishes the Steam-specific Early Access and Playtest rules. Sources were opened and read September 8, 2026. Worksheets, change cards and the fictional hours example are original editorial tools, not observed studio results.

## Frequently asked questions

**Can I fund an indie game while keeping my day job?**

That is a possible project arrangement, not a guarantee that the money or hours will be sufficient. Record affordable contributions and realistic development capacity separately. Check relevant employment and intellectual-property agreements with a qualified lawyer. Do not treat this general guide as advice to leave a job or risk essential savings.

**Should I put unpaid client invoices into the available budget?**

Keep expected receipts separate from cash already received. Record the agreed conditions and likely payment dates, then test a later-payment scenario against commitments that remain due. An invoice total is not automatically spare game-development money. Your accountant can help distinguish project planning from formal accounting and tax obligations.

**How do I calculate a cash-flow closing balance?**

Add cash received to the opening balance, then subtract cash paid. For a forecast, use clearly labelled estimates and carry the resulting closing balance into the next period. Compare actual results with the original forecast. A positive eventual total does not establish that every earlier payment can be met on time.

**Can I sell Steam Playtest access to finance development?**

No. Valve describes Steam Playtest as free and prohibits selling access or monetising it through in-game transactions. It is a testing feature, not a funding product. Steam Early Access is a different programme with its own requirements; it should not be treated as guaranteed revenue that will finance completion.

**When should a self-funded project reduce scope?**

Our editorial approach is to review scope when proposed work no longer fits available resources, obligations become unfunded or important assumptions fail. Record what changes in the cash and capacity plans before accepting more commitments. Get qualified financial or legal advice where personal essentials, borrowing, rights or binding terms are involved.


---

# Video Game Revenue Models: How the Main Options Work

> Common video game revenue models include a one-time premium purchase, paid downloadable content, consumable and non-consumable in-game purchases, subscriptions or time-limited passes, advertising, licensing, and combinations of these. The model defines who pays, when, for what entitlement, and what ongoing service the studio must support. Revenue is not profit: platform share, tax, refunds, discounts, user acquisition, content production, hosting, customer support, fraud, and development costs all affect the outcome.

Source: https://gamingindustry247.com/video-game-revenue-models/  
Publisher: Playable Business  
Published: 2026-07-19  
Updated: 2026-08-25

## A revenue model defines payer, timing, entitlement, and ongoing promise

Video games commonly earn through a one-time premium purchase, paid downloadable content, consumable and non-consumable in-game purchases, subscriptions or time-limited passes, advertising, licensing, and combinations of these. The model decides who pays, when, what they receive, whether access expires, and what continuing work the studio must support.

Revenue is not profit. Platform share, retailer terms, tax, refunds, chargebacks, discounts, user acquisition, development, content, hosting, moderation, customer support, licences, and revenue-sharing agreements all sit between player spending and an economic result.

## Compare the main models

| Model | Player transaction | Typical promise | Main operating burden | Central risk |
|---|---|---|---|---|
| Premium purchase | Pay once for base entitlement | Defined game access under licence terms | Launch, support, discounts | Front-loaded discovery and sales |
| Paid DLC or expansion | Pay for additional content | Specific add-on entitlement | Content production and compatibility | Fragmentation or weak attachment |
| Consumable purchase | Repeat purchase of depleted item | Currency, resource, boost, or use | Economy, fraud, support, compliance | Pressure, imbalance, spending harm |
| Non-consumable purchase | One-time permanent entitlement | Cosmetic, feature, level, or pack | Catalogue and entitlement support | Value clarity and content cost |
| Subscription | Recurring payment | Ongoing access or benefits | Continuous service and cancellation | Churn and continuing obligations |
| Time-limited pass | Purchase for a defined period or season | Progression track or temporary access | Cadence, progression, expiry rules | Fatigue and unfinished value |
| Advertising | Advertiser funds impressions or actions | Free or subsidised player access | SDKs, privacy, brand safety | Intrusion, privacy, dependency |
| Licensing and ancillary | Partner pays for rights or products | Use of IP, technology, or distribution rights | Rights management and approvals | Brand control and deal concentration |

The table describes structures, not performance. No model contains a hidden guaranteed conversion rate.

## Premium purchase: a clear front door

Players pay once for the base game. That can support a finite, complete experience with a simple value proposition. Premium releases may still add paid expansions, cosmetics, subscriptions, or special editions, so “premium” does not always mean one transaction forever.

The model concentrates attention around launch and later discounts. Discovery, wishlists, reviews, platform featuring, marketing, regional pricing, refund behaviour, competition, and release quality affect results.

For players, the important terms include platform account dependency, offline access, server requirements, licence, refund rules, and whether online features may end. A purchase can grant durable use without transferring copyright ownership.

For studios, a premium price does not eliminate post-launch work. Compatibility updates, support, security, localisation, certification, and community communication continue.

## Paid DLC and expansions: sell a defined addition

Downloadable content can add story, maps, characters, modes, cosmetics, music, or tools. An expansion usually signals a larger addition, but stores and publishers use the terms differently.

The business depends on the installed base, engagement, content appeal, price, platform policy, and production cost. It can extend a game’s commercial life and fund more content, while also fragmenting multiplayer populations or confusing edition ownership.

Entitlement design needs clear answers:

- Does the add-on require the base game?
- Does every multiplayer participant need it?
- Is content shared across platforms or accounts?
- Can it be refunded separately?
- What happens when a bundle overlaps prior purchases?
- Is the add-on available after servers or licences change?

Do not infer DLC profitability from store visibility. Public unit counts rarely reveal discounts, regional mix, platform deductions, or production costs.

## Consumable purchases: repeatable spending with a design duty

Apple’s current [in-app purchase definitions](https://developer.apple.com/help/app-store-connect/reference/in-app-purchases-and-subscriptions/in-app-purchase-types/) describe a consumable as depleted through use and purchasable again. In games, examples can include virtual currency, resources, lives, or boosts, depending on implementation.

Consumables can fund continuous content and allow flexible spending, but they create substantial design and consumer-protection responsibility. Teams must address:

- clear real-money cost and currency conversion;
- purchase confirmation and receipts;
- age-appropriate controls;
- refunds and chargebacks;
- fraud and account theft;
- balance between spenders and non-spenders;
- regional and platform rules;
- randomised rewards where used;
- limits, reminders, and parental tools.

This article does not claim all microtransactions are exploitative or harmless. Evaluate the concrete mechanics, audience, disclosures, and pressure.

## Non-consumable purchases: permanent item, ongoing entitlement work

A non-consumable is ordinarily bought once and does not expire through use. It may unlock a cosmetic, character, level pack, feature, or permanent upgrade.

The transaction can feel easier to understand than repeatable currency because the player sees a specific item. The studio still needs entitlement restoration, account migration, catalogue presentation, support, and compatibility across updates.

“Permanent” requires context. It can mean persistent within an account and operating game, subject to terms and service continuity—not ownership of the underlying asset or a promise that servers will run indefinitely.

Non-consumables also carry content-production cost. A large catalogue can increase QA, download size, interface complexity, and art pipeline load.

## Subscriptions: recurring payment for recurring value

An auto-renewable subscription charges again until cancelled under its terms. It may provide catalogue access, premium features, monthly items, server access, or other continuing benefits. A platform catalogue subscription and an individual game subscription have different economics and relationships.

Subscriptions smooth timing only when people continue to perceive value. They also create obligations: reliable service, new or maintained content, billing clarity, cancellation, entitlement checks, customer support, taxes, and platform compliance.

The analyst should ask:

- What continues only while subscribed?
- Which items remain after cancellation?
- Is renewal automatic?
- How and when can price or benefits change?
- Does access require an online check?
- Who owns the customer relationship?

Do not multiply a public subscriber count by a sticker price and call it revenue. Trials, bundles, regional prices, platform deals, promotions, churn, family access, and recognition periods make that arithmetic fictional.

## Passes: time, progression, and expiry

A season or battle pass commonly offers a progression track for a defined period. It may be sold as a non-renewing purchase, included in a subscription, or implemented through another entitlement.

Its value depends not only on content but on the time and play required to unlock it. Good analysis separates:

- purchase price;
- immediate entitlements;
- earned progression rewards;
- free and paid tracks;
- expiry date;
- catch-up or rollover rules;
- automatic renewal, if any.

A pass can structure a live content cadence. It can also create pressure, fatigue, or unused paid value. Those are player-experience outcomes, not merely finance columns.

## Advertising: another customer enters the design

Advertising can support free access through impressions, video views, offers, installs, sponsorship, or other arrangements. The player may not pay money, but attention and data practices become part of the exchange.

The business must account for ad-network policy, privacy consent, age, targeting, SDK security, measurement, fraud, frequency, inappropriate creative, regional law, and the effect on retention. Apple’s [business-model overview](https://developer.apple.com/app-store/business-models/) explicitly frames display advertising as a model and warns developers about relevance, quality, data use, and engagement.

Advertising revenue varies with audience, geography, format, fill, rates, fraud, and season. Do not invent a per-player value.

## Licensing and ancillary revenue: monetise rights, not just play

A game company may license its IP for merchandise, film, television, publishing, location-based entertainment, collaborations, or another game. It may license technology or receive distribution and platform guarantees.

These deals can diversify revenue and extend awareness while introducing approvals, brand risk, manufacturing dependency, minimum guarantees, royalties, territory, term, audit rights, and rights reversions. Public announcements often omit financial terms.

Merchandise sales are not automatically game revenue in corporate reporting; classification and counterparty structure vary. Analyse the disclosed business, not the logo on a T-shirt.

## Hybrid models create a stack of promises

A paid game can sell expansions and cosmetics. A free game can combine advertising, purchases, and a pass. A subscription catalogue can include games that also sell DLC. Steam’s current [pricing documentation](https://partner.steamgames.com/doc/store/pricing) lists full-game purchase, DLC, in-game microtransactions, and recurring subscriptions among supported models.

Hybrid design can diversify receipts, but it also multiplies:

- store disclosures;
- entitlement states;
- refund cases;
- player segments;
- balance and fairness questions;
- customer support paths;
- analytics and accounting.

The more layers a game uses, the more plainly it should explain what each purchase does.

## Early Access is a release state, not one revenue model

An [Early Access game](/early-access-games-explained/) may use premium purchase, free distribution, DLC later, or another permitted model. On Steam, Early Access provides a current playable unfinished game; Valve says it is not crowdfunding and customers should buy based on the current state.

Early Access receipts do not remove funding risk. The team still needs a plan if sales are below expectations, plus support, communication, build operations, and feedback processing while development continues.

## Trace money with a waterfall, not multiplication

For analysis, build a conceptual waterfall:

> gross player spending  
> − sales tax or VAT treatment  
> − refunds and chargebacks  
> − platform, retailer, and payment deductions  
> = net receipts to the contracted payee  
> − recoupable costs or advances where agreed  
> − revenue shares, licences, royalties, and partner payments  
> − operating and development costs  
> = an economic result defined by the company’s accounting

The order and definitions vary. Never insert guessed percentages into an undisclosed contract.

The [developer-versus-publisher guide](/game-developer-vs-publisher/) explains why the store publisher may not be the only party sharing receipts. The [production-stage map](/game-development-stages/) shows the work those receipts must fund before and after launch.

## Evaluate a model with seven questions

1. Who can play without paying?
2. Who pays, when, and how often?
3. What exact entitlement does each transaction grant?
4. Which ongoing service or content is promised?
5. What cost grows with players, time, or content cadence?
6. What consumer, platform, privacy, age, and regional rules apply?
7. What happens when support, renewal, a season, or the service ends?

Those questions describe the model without inventing performance. A business model is not a moral verdict or a revenue forecast. It is a structured exchange whose design, execution, audience, and obligations determine whether it works.

## Frequently asked questions

**What is a premium game business model?**

Players pay once for the base game, although expansion, DLC, or cosmetic offers may still follow. The model gives a clear initial transaction and can fit finite experiences, but commercial performance depends heavily on discovery, pricing, launch quality, discounts, and platform context. ‘Premium’ does not guarantee ownership forever; licence terms, servers, accounts, and platform access still matter.

**How do free-to-play games make money?**

They commonly earn through optional purchases, advertising, subscriptions, passes, or partnerships while allowing entry without an upfront price. Only some players may pay, so the design depends on reach, retention, content, operations, and payment systems. There is no responsible universal payer percentage or revenue forecast. Ethical evaluation should examine clarity, pressure, age suitability, randomisation, fairness, and spending controls.

**What is the difference between consumable and non-consumable purchases?**

A consumable is depleted through use and can be purchased again, such as certain virtual currencies or resources. A non-consumable is bought once and does not expire through ordinary use, such as permanent content or a feature entitlement. Apple documents these as distinct in-app purchase types; exact restoration and cross-platform access depend on platform rules and game implementation.

**Are battle passes subscriptions?**

Not automatically. A pass may be a non-renewing, time-limited purchase that grants progression rewards, while a subscription usually creates recurring access or benefits and may renew automatically. Stores and games implement these differently. Check duration, renewal, entitlement, expiry, progression requirements, and cancellation language instead of inferring the commercial structure from the word ‘pass.’

**Why is game revenue not the same as profit?**

Gross player spending can be reduced by platform or retailer share, tax, refunds, chargebacks, discounts, regional pricing, payment processing, licences, revenue shares, and recoupment. The business also pays development, marketing, acquisition, hosting, moderation, support, compliance, and ongoing content costs. Without a company’s accounting and contract detail, outsiders should not convert store ranking or player count into profit.

**Can a game combine several revenue models?**

Yes. A paid base game may sell expansions and cosmetics; a free game may combine advertising, purchases, and a pass; a subscription catalogue may also offer separately purchased content. Hybrid design can diversify revenue but also complicates player expectations, entitlements, refunds, balancing, support, and platform compliance. Analyse each transaction and promised benefit rather than assigning one label to the whole product.


---