Start Building

Lesson 5: Project Management & Timeline Planning

You have a concept, a business model, a budget, and a legal structure. Next is turning that into a clear project plan and timeline so you can move from planning to production without burning out or missing key milestones. This lesson walks you through defining scope, breaking work into phases, setting milestones, and building a realistic timeline for your first indie game.

What You'll Learn

By the end of this lesson you will be able to:

  • Define project scope and core features so you know what is in and out for v1
  • Break development into phases (pre-production, production, polish, launch) with clear outcomes
  • Set milestones and deadlines that match your capacity and budget
  • Use simple tools (spreadsheet, Trello, Notion) to track tasks and progress
  • Adjust the plan when scope or life changes without losing direction

Why This Matters

A clear plan keeps you from over-scoping, helps you say no to feature creep, and gives you checkpoints to celebrate. A realistic timeline reduces crunch and burnout. You do not need a Gantt chart for a first project; you need a short list of phases, milestones, and a way to track what is done and what is next.

Step 1: Define Scope and Core Features

Before you schedule anything, lock what "done" means for your first release.

Core features (must-have for v1)

  • List the minimum set of features that make the game playable and shippable (e.g. main loop, 5 levels, basic UI, save/load, one platform).
  • Write one sentence: "Version 1 is done when [player can do X and I have Y in the build]."
  • Keep the list short. Cut everything that is not essential for a first release.

Out of scope for v1

  • List features you are explicitly not doing for launch (e.g. multiplayer, 20 levels, 3 platforms). This makes it easier to say no later.
  • You can add them in post-launch updates if the game does well.

Pro Tip: Use a "core loop" description: in one sentence, what does the player do most of the time? Everything that does not support that loop is a candidate to cut or defer.

Common mistake: Defining scope as "everything I can imagine." That leads to endless development. Define the smallest set that makes the game fun and shippable, then ship.

Step 2: Break Development into Phases

Split the project into phases so you have clear stages and outcomes.

Pre-production (concept to greenlight)

  • Finalize design doc, art style, and tech stack.
  • Create a vertical slice or prototype that proves the core loop.
  • Outcome: You and (if applicable) your team agree the project is worth full production.

Production (main development)

  • Build levels, content, and systems according to your core feature list.
  • Integrate art, audio, and code; playtest regularly.
  • Outcome: Feature-complete build that matches scope.

Polish and QA

  • Bug fixing, balance, performance, and UX polish.
  • Internal or external playtesting and feedback.
  • Outcome: Stable build ready for store submission or beta.

Launch and post-launch

  • Store pages, marketing beats, release, and first patch.
  • Outcome: Game live and first round of feedback and metrics.

Pro Tip: Put rough time percentages on each phase (e.g. pre-production 15%, production 60%, polish 20%, launch 5%). If you have 6 months total, that is about 1 month pre-prod, 3.5 production, 1 month polish, 2 weeks launch. Adjust to your project size.

Common mistake: Skipping pre-production and jumping straight into full production. A small prototype or vertical slice saves time by catching design or tech problems early.

Step 3: Set Milestones and Deadlines

Milestones are checkpoints, not every single task. They should be measurable and few.

Example milestones for a small indie game

  1. Pre-production complete – Design doc approved, vertical slice playable (e.g. 4–6 weeks).
  2. Alpha – All core features in, playable start to end, placeholder art/audio OK (e.g. 2–3 months after pre-prod).
  3. Feature freeze – No new features; only bug fixes and polish (e.g. 2–4 weeks before beta).
  4. Beta – Build stable enough for external testers (e.g. 2–4 weeks before launch).
  5. Launch – Build submitted and released (date set with buffer for store review).

Setting deadlines

  • Work backward from a target launch date (or forward from today if you have no fixed date).
  • Use your budget and capacity: if you have 10 hours per week, do not plan as if you have 40.
  • Add buffer (e.g. 20%) for unknowns, sickness, and scope creep. If you think polish takes 4 weeks, plan 5.

Pro Tip: Make milestones visible (e.g. on a one-page roadmap or in your task tool). Review them weekly; if you slip, adjust the next milestone or cut scope instead of crunching.

Common mistake: Setting one big "launch" date with no intermediate milestones. You need alpha and beta dates so you can correct course before it is too late.

Step 4: Choose Tools and Track Progress

You do not need expensive software. You need one place for: scope, phases, milestones, and tasks.

Option A: Spreadsheet (Google Sheets, Excel)

  • One sheet: phases and milestones with target dates.
  • Another sheet: task list (phase, task, owner, status, due date).
  • Use filters or conditional formatting to see what is late or blocked.

Option B: Kanban (Trello, Notion, etc.)

  • Columns: To Do, In Progress, Review, Done (or match your phases).
  • Each card = one task or milestone. Move cards as you progress.
  • Pin the milestone dates in the card titles or in a separate roadmap view.

Option C: Hybrid

  • Roadmap (one page): phases and milestone dates.
  • Task list or board: day-to-day work. Link tasks to milestones so you can see what is left for each milestone.

Pro Tip: Review the list weekly. If the same task sits in "In Progress" for weeks, break it down or reprioritize. If you keep adding tasks without moving the launch date, you are expanding scope; cut something or push the date.

Common mistake: Using five different tools (notes, email, Discord, spreadsheet) so nothing is the single source of truth. Pick one place for "what we are building" and "what we have to do" and stick to it.

Step 5: Adjust the Plan Without Losing Direction

Plans change. The goal is to adjust consciously instead of drifting.

When to adjust

  • You hit a milestone late – Move the next milestones (and possibly launch) or cut scope to get back on track.
  • Scope creep – Someone (or you) wants a new feature. Check: is it in the core list? If not, add it to "post-launch" or say no.
  • Life or capacity changes – Reduce hours per week in the plan, extend the timeline, or cut scope so the plan is realistic again.

How to adjust

  • Update the roadmap and milestone dates in one place.
  • Communicate to collaborators (if any) what changed and why.
  • Revisit the "core features" list; if you cut something, make sure it is explicit so it does not sneak back in.

Pro Tip: Once per month, compare "what we said we would do" to "what we did." If you are always late, your estimates are too optimistic; add more buffer or reduce scope next time.

Common mistake: Refusing to change the launch date when everything is slipping. A delayed but finished game is better than an on-time but broken or abandoned one.

Mini Challenge

  1. Write your v1 scope in one sentence: "Version 1 is done when [X]."
  2. List three features that are explicitly out of scope for v1.
  3. Break your project into four phases (pre-production, production, polish, launch) and give each a target duration in weeks.
  4. Set five milestones with target dates (e.g. vertical slice, alpha, feature freeze, beta, launch).
  5. Create a simple task list or board with at least the next 10 tasks and link them to a milestone.

Save this; you will use it when you plan art direction and asset creation in Lesson 6 and when you prepare for launch later in the course.

Troubleshooting

"I do not know how long things take."
Use your vertical slice or first few tasks to calibrate. If one level took 2 weeks, 5 levels might be 8–10 weeks with buffer. Update estimates as you learn.

"I keep adding features."
Keep a "v2 or post-launch" list. When a new idea comes up, put it there instead of into the current scope. Review that list after launch.

"I work alone and get overwhelmed."
Focus on one phase at a time. For this week, list only the tasks for the current milestone. Do not look at the full project every day; look at the next 5–10 tasks.

"My collaborator has different expectations."
Align on the one-sentence scope and the milestone list. If you disagree on scope or dates, fix that before adding more tasks.

Recap and Next Steps

You have:

  • Defined scope and core features so v1 is clear and bounded.
  • Broken development into phases (pre-production, production, polish, launch) with outcomes.
  • Set milestones and deadlines that match your capacity and budget.
  • Chosen a simple way to track tasks and progress.
  • Planned how to adjust the plan when things change.

In Lesson 6: Art Direction & Asset Creation, you will turn your art style and scope into a concrete asset list and pipeline so art supports your timeline instead of blocking it.

For more on planning and production, see our guides on project management for indie games and launch checklists. Bookmark this lesson and revisit your roadmap when you feel lost or when scope creeps.