Shipping

Scope like a shipper: 3 lanes in 12 weeks

Learn a solo-friendly weekly cadence that turns “a year” into 36 concrete deliverables across content, systems, and polish.

AI Image AnnoMotion
AI Image AnnoMotion

If you’ve ever written “ship the game” on a sticky note and then spent a month arguing with yourself about what counts as progress, this is for you: a simple scope method that treats your year like a set of repeatable weekly outputs.

The core idea is to ship through three parallel lanes—content, systems, and polish—using a 12-week cadence. That gives you a realistic way to answer: What will I have made by next Friday? and What will I still be able to show after a few weeks of inevitable surprises?

The 3 lanes: what you’re actually building

A solo project tends to get stuck when everything is lumped into one bucket called “the game”. Break that bucket into three lanes so you can keep moving even when one part is messy.

1) Content lane (stuff in the world)

Content is what the player experiences directly: levels, encounters, items, quests, enemies, dialogue, props—anything you can point at and say “this exists”.

Rule of thumb: content is “countable”. If you can’t reasonably count it, you’ll struggle to ship it on a weekly schedule.

2) Systems lane (the rules behind it)

Systems are how the game behaves: movement rules, combat logic, inventory rules, quest state transitions, save/load, progression gating, AI behaviour loops—anything that makes content run.

Rule of thumb: systems are “reusable”. A system should let you add more content without redesigning everything from scratch.

3) Polish lane (the feel and finish)

Polish is the layer that makes the experience coherent: animations timing, camera feel, UI clarity, audio feedback, VFX readability, difficulty tuning, bug fixes that remove friction, tutorial clarity, and “it feels right” adjustments.

Rule of thumb: polish is “player-visible quality”. It’s not “clean code for its own sake”; it’s changes that reduce confusion, mistakes, or dead-ends.

The weekly cadence: 12 weeks, 3 lanes, 12 weeks * 3

To make “a year” concrete, you need a repeatable unit of planning. Use 12-week cycles as your planning horizon, and within each cycle keep each lane producing something every week.

Here’s the practical shape:

  • Each lane has one shippable deliverable per week.
  • That means 3 deliverables per week.
  • Over 12 weeks, you get 36 deliverables across the year’s first cycle.

You’ll notice this is intentionally not “a feature per week”. Features are too big to define cleanly early on, and they invite thrash when scope shifts. Instead, deliverables are smaller and easier to finish.

What counts as a “shippable deliverable”?

A deliverable is something you can:

  • show in the game (even if it’s rough),
  • test in a short play session,
  • and decide “done” without needing another deliverable first.

Examples that usually work:

  • Content: “One playable mission with a win condition and one enemy encounter.”
  • Systems: “Inventory item pickup and equip flow works end-to-end with save/load.”
  • Polish: “UI readability pass for health/stamina, with audio feedback on damage events.”

Examples that usually fail:

  • “Improve combat.”
  • “Make it fun.”
  • “Refactor the codebase.”

Those may be necessary, but they’re not shippable deliverables by themselves.

How to pick deliverables without lying to yourself

Most solo thrash comes from picking deliverables that depend on other deliverables being finished first, then discovering the dependency chain is longer than expected.

Use this selection checklist each week:

  1. Can I complete it in one week?
    If the answer is “maybe, if nothing goes wrong”, split it. Your future self needs a deliverable that survives reality.

  2. Does it have a visible end-state?
    If you can’t describe what “done” looks like in one sentence, it’s not ready to be scheduled.

  3. Does it reduce future work?
    Systems lane deliverables should make the next content additions faster. Polish lane deliverables should remove friction so you stop paying the same “confusion tax” repeatedly.

  4. Is it testable immediately?
    If you can’t test it in a short session, you’ll spend time guessing. Guessing is where schedules go to die.

A worked example: a small action game

Say your game is an action RPG prototype with basic combat and a few rooms.

Week 1

  • Content: Add one new room layout with a single encounter type.
  • Systems: Implement “attack hit detection + damage application” end-to-end.
  • Polish: Add hit feedback (screen shake or camera nudge + readable hit sound).

Week 2

  • Content: Add a second encounter that uses the same combat rules.
  • Systems: Add enemy death handling (loot drop trigger + despawn) and confirm it works with the first two encounters.
  • Polish: Tune enemy wind-up timing so attacks are readable at normal player pace.

Week 3

  • Content: Add a short objective: “defeat all enemies in the room” with a clear victory screen or state.
  • Systems: Implement checkpointing for rooms (or at least a restart that doesn’t break state).
  • Polish: UI pass for health + enemy indicators, so the player understands what’s happening without guessing.

Notice the pattern: content keeps expanding, systems keep making content easier to add, polish keeps the experience coherent. Even if Week 2’s systems deliverable uncovers a bug, you still have something shippable in the other lanes.

Turning “one year” into a plan you can keep

A year sounds like a single plan. In practice it’s multiple 12-week cycles, each with its own lane deliverables. The trick is to avoid treating the cycles as “all features, then polish later”.

Instead:

  • Cycle 1 proves your loop: content can be added, systems can support it, and polish keeps it playable.
  • Cycle 2 scales: you add more content faster because systems are stronger, and polish focuses on the most common player pain points.
  • Cycle 3 consolidates: you reduce repeated friction and tighten the experience until your game stops feeling like a prototype.

You don’t need to know the entire year’s end-state on Day 1. You need a cadence that keeps you shipping while the design clarifies.

A simple way to start this week

Pick a 12-week cycle target and define your lanes for the project you can test right now.

Do this next:

  1. Write a list of 5 content deliverables you could plausibly finish in a month (missions, rooms, encounters, items—whatever fits your game).
  2. Write a list of 5 systems deliverables that would make those content pieces easier to build or complete.
  3. Write a list of 5 polish deliverables that would remove the most obvious player confusion or frustration.

Then choose one from each lane for this week—content, systems, polish—and define “done” in one sentence for each. Once you’ve done that, your next week’s scope becomes a repeatable decision, not a new argument with yourself.

Everything above was made with these tools.

Sprites, tilesets, icons, UI, music, sound effects, video and 3D — from a prompt, engine-ready for Unity, Godot and Unreal. New accounts get free credits once they verify their email.

Start free Sign in Continue with Google