← All books
Scattered development blocks resolving into a finished release doorway on the cover of Ship the Game

Volume 05 / Production & Release

Ship the Game

The Indie Developer's Guide to Actually Finishing

Finish a game you can stand behind. Define a useful minimum, build complete slices, cut with purpose, manage bugs, and prepare a dependable release.

Length
17 pages
Reading time
16 minutes
Format
PDF · 112 KB
Price
Free
Download PDF ↓Read a preview →

First edition · October 2026 · Published by Vertex Arc

Inside the guide

MVPs and milestonesFeature cutsQA and polishRelease and post-launch

Contents

  1. 01Recognize idea addictionPage 5 ↗
  2. 02Define a realistic minimum complete gamePage 6 ↗
  3. 03Turn milestones into observable outcomesPage 7 ↗
  4. 04Build vertically before expanding horizontallyPage 8 ↗
  5. 05Cut features with a planPage 9 ↗
  6. 06Manage bugs by impact and recoveryPage 10 ↗
  7. 07Use playtesting to make decisionsPage 11 ↗
  8. 08Polish what supports the whole gamePage 12 ↗
  9. 09Prepare the build and the promisePage 13 ↗
  10. 10Plan the first update before launchPage 14 ↗

Also includes an introduction, practical exercises, a final checklist, and a conclusion.

Introduction

Finishing a game means producing a complete experience that another person can obtain, understand, play, and leave without needing its developer nearby. It includes the title screen, the last encounter, the settings, the build process, the support information, and the awkward edge cases between them. Those parts are less visible than a new mechanic, but they are part of the game you are making.

This book follows an original hypothetical small project called Signal Harbor. The player repairs navigation beacons across a compact coastal map. The team has a short campaign, a few reusable interactions, and limited production time. The example is not a claim about a shipped Vertex Arc project. It is a practical frame for decisions about scope, milestones, testing, and release.

The advice is deliberately modest. You do not need a large production department to write an exit criterion, preserve a working build, or decide which feature to cut. You do need to make those decisions visible and follow them when new ideas become more exciting than unfinished work.

Keep a release definition, a milestone board, a bug list, and a decision log. Make them short enough to use. The purpose is not to create administration around the game; it is to stop hidden obligations and repeated debates from consuming the time needed to finish it.

Read chapter 01

01 / Recognize idea addiction

The idea

A new idea offers possibility without the accumulated constraints of an existing project. That makes starting feel easier than finishing. The danger is not having ideas; it is using them to avoid decisions about the game already in progress. Capture new concepts in a separate place so they remain available without automatically becoming current work.

Ask what problem a proposed feature solves in the current experience. If the answer is only that it would be exciting to build, it may belong in a future experiment. Creative exploration can still have a place, but give it a bounded purpose and a return point to the main project.

Example

Signal Harbor's developer wants to add sailing after the beacon interactions already work. Sailing could become a separate game loop with controls, collision, camera, art, and testing costs. The idea goes into an experiment list. The current release keeps travel simple because its intended experience is repairing and reconnecting the harbor, not mastering a boat.

Key takeaway

Keep new ideas without letting them silently replace the project you committed to finish.

Try this

Review your last five new feature ideas. For each, identify the player problem it solves and the existing work it would displace. Move ideas without a clear answer out of the current milestone. Reserve a small future review point so postponement does not feel like forgetting.

Developer note

If you repeatedly avoid the same unfinished system, investigate why. It may be unclear, too large, technically blocked, or no longer valuable. A smaller task or a deliberate cut is more useful than another unrelated feature.

Keep reading — download the book ↓
All five books →