Self-Funding an Indie Game: Cash and Capacity Planning
- How can you fund your own indie game?
- What does self-funding actually mean?
- What should the cash plan contain?
- Why is an invoice not the same as cash received?
- How do you stop counting the same hours twice?
- What changes when client work pays the bills?
- Which scope changes deserve a new decision?
- Can Early Access or a paid playtest fill the gap?
- When should you pause or seek another funding route?
- Sources
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 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 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 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:
- Identify the period being planned.
- State the hours realistically available for project work.
- Assign hours to specific tasks, including administration, integration and testing.
- Record client commitments separately.
- 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 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 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 covers the additional public-development responsibilities.
Steam 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.