Blog

Getting Started Indie Game Development: 90-Day Plan

By Lauren "Celeste" Rousell · November 2, 2026 · 10 min read

Getting started indie game development means picking one engine, cutting scope until a vertical slice fits 90 days, and applying to ID@Xbox or PlayStation Partners before you ship. This roadmap gives you the week-by-week plan, scope-cutting decision rules, and verified console requirements so your first game actually ships.

What do you need to get started in indie game development?

Four things: an engine, version control, a task board, and a scope small enough to ship. Everything else can wait.

The four disciplines you'll wear as a solo dev or tiny crew

Design, art, code, and audio. You don't need to master all four, but you need a plan for each, even if that plan is "placeholder art, free asset pack audio." What kills first projects isn't weak skill in one discipline; it's no system connecting them, so a broken build at 11 PM before a milestone turns into archaeology through Discord threads instead of a fix (see Butterstack on game dev task management).

What your tool stack should cost at day one

Godot is free. Unity's Personal plan is free under its revenue threshold, with Pro for larger studios (see Unity pricing). Version control: Git is free. A task board like Inferno is free too. Your real budget goes to your time.

How do you choose between Unity, Godot, and Unreal for your first indie game?

Pick by discipline mix and target platform, not by engine benchmarks. A tiny crew with one programmer and two artists ships faster on the engine whose asset pipeline matches their strengths.

Unity for console-bound teams that need asset store depth

Unity is the default for 2-8 person teams targeting PlayStation or Xbox. Its asset store covers art, audio, and middleware gaps that a tiny crew can't fill in-house, and console porting partners know its build pipeline well.

Godot for 2D and zero licensing friction

Godot is free and open source with no revenue-based terms, which matters when your first game might earn almost nothing. For 2D games, its lightweight editor and GDScript keep a small team shipping without fighting the tool.

Unreal when 3D fidelity is the product

If your vertical slice sells on visuals, Unreal's renderer and Blueprints let artists contribute without deep C++. The trade is a heavier editor and a steeper build pipeline for a small team.

Recommendation matrix

Whatever you choose, get the backlog into one shared workspace early. A tool like Inferno keeps design, art, code, and audio tasks in the same board your engine's builds feed into.

How do you scope a first indie game so it actually ships?

The vertical slice rule: prove the core loop in 3 weeks

Build one playable slice of your game, start to finish, in three weeks. If the core loop is not fun with placeholder art and no audio, no amount of content will fix it. A slice that ships proves your pipeline works: code, art, and build steps all connect. If you use an engine like Godot, exporting across desktop platforms is already handled for you (Godot's documentation covers the export workflow), so scope, not tech, is your bottleneck.

Five scope-cutting decision rules

1. One mechanic budget. Pick a single core mechanic. Every feature must serve it or get cut.
2. Cut by discipline, not by feature. If audio would take three weeks, ship with two sounds, not a composer.
3. No second environment. One art style, one tileset, one palette.
4. Placeholder until fun. Nothing gets polished before the loop is fun.
5. Write kill criteria before you build. "If this isn't playable by week 6, we cut it" beats deciding at midnight.

Track these rules on a board your whole crew sees. We built Inferno for exactly this: columns you name yourself, a shared backlog, and a sprint field and labels on every task, so cut features stay visibly parked and scope decisions stay decisions.

Why scope creep kills more first games than bad code

Most first games don't fail on bugs; they fail because the design grew after the fun was proven. Every "small addition" multiplies across art, code, and audio. Freeze the design at your vertical slice, log new ideas in a backlog for game two, and ship the version you scoped.

What should your first 90 days of indie game development look like week by week?

Treat the 90 days as four blocks: prototype the core loop (weeks 1-3), build a vertical slice (weeks 4-6), run production in sprints (weeks 7-10), then polish and prep your submission build (weeks 11-13). Each block has one deliverable. If a block ends without its deliverable, cut scope before moving on, not after.

Weeks 1-3: prototype the core loop

Pick one mechanic and build nothing else. A gray-box level, placeholder art, and a playable loop by day 21. If the loop is not fun with programmer art, no amount of polish will fix it later. Log every idea that appears during prototyping in your backlog and refuse to act on any of them until week 4.

Weeks 4-6: build the vertical slice

The slice is one minute of your game at shipping quality: final art style, sound, UI, and feel. This is where discipline matters most, because the slice defines the quality bar for everything that follows. If your slice takes three weeks for 60 seconds of game, your full scope estimate is that pace multiplied across every minute of the game, and that math will usually force cuts. Make them now, on paper, while the game is still small enough to cut.

A tiny crew that skips this step discovers at month eight that a two-hour game actually takes two years, and most dead indie projects died exactly there. Write the cut list down, get every member of the crew to sign it, and treat it as the contract for the next 60 days. Tools like Trello can hold the list, though a game-specific board such as Inferno keeps art, code, and audio tasks in one pipeline (see how it compares in Inferno vs Trello).

Weeks 7-10: production in sprints

Run two-week sprints with a fixed sprint goal, and demo the build to the whole crew at the end of each one. Keep the backlog groomed weekly so scope creep gets rejected in planning, not discovered in the build.

Weeks 11-13: polish, demo build, and submission prep

Spend the final block on bugs, performance, and a clean demo build. Capture trailer footage, write your store copy, and assemble the materials console submissions require, which the next section covers in detail.

What are the steps to get your indie game on PlayStation and Xbox?

ID@Xbox: how the application and dev kit process works

ID@Xbox is open to indies and free to apply to. You submit your team and game pitch through the official site, and once accepted you sign the developer agreement, get access to dev kits, and publish under your own name with revenue terms agreed directly with Microsoft. Build a playable prototype before applying; the program expects a real project, not an idea.

PlayStation Partners: requirements for small teams

Sony's self-publishing path runs through the PlayStation Partners portal. You register your studio, describe your game, and Sony reviews the concept before granting dev kit access and publishing rights. Unlike Xbox, Sony historically reviews each title individually, so a clear vertical slice and milestone plan help your application. Both platforms expect a registered business entity, so get that paperwork moving early.

Certification and submission realities for a 2-8 person studio

Both console makers require TRC/XR checklist compliance before release, which means planning weeks of submission and fix cycles into your schedule, not days. Budget for this in your 90-day plan: certification failures on save handling, error logging, or suspend/resume behavior are the usual suspects for a tiny crew. Track each requirement as its own task so nothing slips, which is exactly why we built Inferno around milestone discipline. If you ship on Unreal instead, note that royalties apply after your first $1 million in gross revenue (see the Unreal Engine EULA).

How much time and money do you need before your indie game earns revenue?

Plan for 12 to 24 months from first commit to first dollar for a first shippable game, even with a tiny crew and a tight scope. Most of that is production time, not waiting on platforms.

Store fees and fixed costs you can plan around

The fixed costs are small and known up front. Steam's Direct fee is $100 per game. Console is free to apply but gated: ID@Xbox handles application review and dev kit allocation, and the process takes time you should start early. Budget a few hundred dollars for a company LLC and store asset creation, and treat everything else as engine and tooling time.

Why your first game is tuition, not revenue

Almost no first game pays back the hours. What it pays back is pipeline: you learn to cut scope, hit a milestone, and ship a build. Price that education honestly when you set your 90-day plan.

When should a solo developer start treating the project like a studio?

The three signals your spreadsheet workflow is failing

First, milestones slip repeatedly with no shared record of why. Second, discipline handoffs break: art lands in a Discord thread, code notes live in a doc, and nobody can reconstruct what "fixed stuff" meant two weeks later. Third, you start dreading Monday because figuring out what changed requires archaeology across three tools instead of reading one board.

What changes when you adopt a game-specific task board

A board built for game pipelines lets you link design docs and code to tasks, so the vertical slice plan and the backlog live in one place. Handoffs between disciplines become explicit: art marked done means code can pick it up without a Discord ping. Scope creep gets visible early, because everything you cut or add sits on the same board as everything you promised.

Where Inferno fits, and where it doesn't

Inferno pulls planning, tasks, and documentation into one workspace for a tiny crew of two to eight, which is exactly the scattered-Trello-and-Discord problem. It's the right move when the three signals above show up. If you're solo and shipping a jam-sized game, a free Trello board is honest enough; adopt a studio workflow when collaboration, not ambition, demands it.

FAQ

Can I start indie game development with no coding experience?

Yes. Pick an engine with a low-code path: Unreal's Blueprints let artists build gameplay logic visually, and Godot's GDScript is beginner-friendly. You still need to learn one of these tools, but you can start with placeholder art and free asset packs while your code skills catch up to your design.

Is Unity still free for small indie teams?

Yes, under the Personal plan's revenue threshold. Unity's pricing page lists Personal as free with Pro reserved for larger studios, so a first project earning little or nothing costs nothing in licensing. If your revenue later crosses the threshold, you upgrade then. Godot remains the zero-friction alternative with no revenue terms at all.

How long does ID@Xbox approval actually take?

Microsoft doesn't publish a fixed timeline, so plan for weeks of review rather than days, and apply before you're ready to ship. Build a playable prototype first, since the program expects a real project rather than an idea. Start the application early in your 90-day plan so review time overlaps production.

Do I need a company registered before publishing on Steam or consoles?

For consoles, yes: both ID@Xbox and PlayStation Partners expect a registered business entity, so start that paperwork early. Steam is more forgiving on registration, but its $100 Direct fee per game applies either way. Budget a few hundred dollars for the LLC and treat it as a fixed, known cost.