Die Last-Mile-Entscheidung: Wann du dein Indie-Spiel veröffentlichst, statt weiter zu polishen

Du kennst das Gefühl. Der Build läuft. Die Tester hassen ihn nicht. Aber jeden Morgen öffnest du das Projekt und reparierst noch eine Sache, die gestern nicht auf der Bugliste stand. Das ist kein Fertigwerden. Das ist der Polish-Loop, und er ist mit Abstand der häufigste Grund, warum ein fast fertiges Indie-Spiel noch ein Jahr lang fast fertig bleibt.

Dieser Guide liefert dir einen Entscheidungsrahmen dafür, wann du dein Indie-Spiel veröffentlichst. Fünf binäre Release-Tore. Ein Cut-Line-Worksheet für deinen Polish-Stapel. Ein Pact-Skript mit Mitwirkenden, das aus "irgendwann bald" ein Steam-Release-Datum macht. Und einen ehrlichen Blick auf die ersten 48 Stunden nach Launch, weil niemand darüber schreibt und genau das zur Hälfte der Grund ist, warum du gerade feststeckst.

Was du brauchst, bevor du loslegst:

• Einen spielbaren Build, der mindestens 30 Minuten ohne Hard Crash läuft
• Eine ehrliche Bugliste, jedes Ticket, noch unsortiert
• Mindestens eine Person außerhalb deines Kopfes, die das Spiel gespielt hat

1. Benenne das Muster: Polish, der sich versteckt, vs. Polish, der shippt

Polish am Ende eines Projekts sieht produktiv aus. Das stimmt nicht immer. Derek Yu, der Spelunky veröffentlicht und dann ein Buch darüber geschrieben hat, hat einen Namen für das, was dann passiert. Er nennt es den Death Loop.

"Es liegt Trost darin, weiter zu arbeiten und Dinge zu verbessern, sich an vertrauten Problemen abzuarbeiten, hinter den Kulissen."

• Derek Yu, Make Games: Death Loops

Der Trost ist das Warnsignal. Wenn die Arbeit dir keine Angst mehr macht, bringt sie dich meistens auch nicht mehr näher an den Release. Die fünf Anzeichen, dass deine Last-Mile-Arbeit Vermeidung ist, kein Fertigstellen:

1. Die Aufgaben, die du zuerst nimmst, sind die, die du schon kannst.
2. Die Aufgaben, die du zuletzt nimmst, sind die, die du "für wenn das Hauptspiel fertig ist" eingeplant hattest.
3. Deine Commit-Messages schrumpfen von "Bosskampf hinzugefügt" auf "Partikel-Alpha angepasst".
4. Du hast den Build seit über zwei Wochen niemandem Neuen gezeigt.
5. Niemand außerhalb deines Kopfes erwartet an einem bestimmten Datum etwas von dir.

Ein anderer Weg, das zu diagnostizieren: schau dir an, was übrig ist. Aus einer Indie-Game-Clinic-Analyse zum Muster am Projektende:

"Wenn du am Ende eines Projekts bist, sind die Dinge, die noch zu tun sind, entweder langweilige, repetitive Sachen - oder Sachen, die du nicht kannst und denen du ausgewichen bist."

Du bist nicht faul. Du bist unbeaufsichtigt. Der Trost, vertrauten Polish runterzugrinden, gedeiht, wenn niemand auf deine Arbeit wartet, um seine eigene anzufangen. Bau die Struktur um, und der Polish-Loop löst sich von allein auf.

2. Mach Bungies Move: Der Scope-Cut, den jedes veröffentlichte Spiel irgendwann macht

Auf der E3 2003 zeigte Bungie eine Halo-2-Demo, die so poliert war, dass sie den Erwartungshorizont für das fertige Spiel festnagelte. Etwas mehr als ein Jahr später war klar: die Erwartung war nicht zu halten. Der ehemalige Bungie-Designer Jaime Griesemer hat in einer Oral History rückblickend so gesagt:

"Wir hatten nicht das Ziel vor Augen, auf das wir eigentlich zugehen wollten."

Also hat Bungie gecuttet. Viel. Das veröffentlichte Spiel hat nicht, was die E3-Demo versprochen hat. Das veröffentlichte Spiel existiert. Die E3-Demo nicht.

Du wirst den Satz "stop building, start shipping" überall im Netz Bungie zugeschrieben finden. Der Spruch wird so oft wiederholt, dass er praktisch zur Folklore der Branche geworden ist, und der Scope-Cut-Moment, den er beschreibt, ist real und dokumentiert. Die Primärquelle für das exakte Zitat ist dünn, also behandle den Satz als geerbte Weisheit, nicht als direktes Bungie-Zitat. Das Verhalten, auf das er zeigt, ist nicht optional.

Jedes Studio in jeder Größe macht diesen Cut. Halo 2 hat ihn gemacht mit 200 Leuten und einer Microsoft-Deadline. Hollow Knight nach drei Kickstarter-Stretch-Goals. Du wirst ihn alleine in einem Arbeitszimmer machen, es sei denn, du baust dir die Struktur vorher auf.

3. Lauf die Fünf-Tor-Checkliste fürs Release durch

Hier ist der Entscheidungsrahmen. Fünf binäre Tore. Wenn die Antwort bei einem "nein" ist, veröffentlichst du noch nicht. Wenn alle fünf "ja" sind, erfindest du kein sechstes.

Tor 1, Crash-Rate. Fünf Tester von außen spielen je 30 Minuten. Weniger als ein Hard Crash insgesamt über die 2,5 Stunden. Das ist nicht "keine Crashes auf meinem Dev-Build". Frische Maschinen, frische Installationen, echte Spieler.

Tor 2, die ersten zehn Minuten. Vier von fünf Fremden erreichen den Core Loop, ohne dass du irgendetwas erklärst. Schau ihnen per Discord-Screenshare zu, wenn nötig. Wenn sie einen Hinweis brauchen, ist dieser Hinweis ein Ship-Blocker, nicht eine Patch-Note.

Tor 3, Core-Loop-Ausdauer. Die Hauptaktivität deines Spiels bleibt interessant für das Dreifache einer Session, die du von einem echten Spieler erwartest. Wenn deine Ziel-Session 20 Minuten ist, brauchst du eine Stunde Core-Loop-Tiefe. Nicht Content. Tiefe.

Tor 4, Content-Untergrenze. Eine 30-Minuten-Session endet auf einem Moment, auf den der Spieler stolz ist. Einen Boss besiegt, etwas freigeschaltet, einen Payoff gesehen. "Spiel läuft" ist nicht die Latte. "Session endet auf einem Peak" ist die Latte.

Tor 5, Audit der Restliste. Öffne deinen Bugtracker. Jeder verbleibende Punkt ist entweder kosmetisch oder strukturell. Kosmetisch geht in Patch 1.1. Strukturell blockiert das Release. Es gibt keine dritte Kategorie. Wenn du dir "nice to have" schreibst, ist der Punkt kosmetisch.

Tim Ruswick, der regelmäßig kleine Spiele released, formuliert die Latte so:

"Du musst lernen, mit good enough zu leben. Du musst auf 80 oder 90 Prozent bleiben und das Ding einfach existieren lassen."

Fünf Tore bestanden, du shippst. Du kriegst kein sechstes Tor namens "aber ich hab' gerade nicht das Gefühl". Das Tor hat keinen Schwellenwert.

4. Setz das Release-Datum laut, und in Steam

Interne Deadlines funktionieren nicht. Du weißt das, weil du alle gerissen hast. Externe Deadlines funktionieren, weil du sie nicht leise verschieben kannst, ohne dass es jemand merkt. Ruswick, nochmal:

"Deadlines scheinen nicht zu funktionieren, wenn ich sie intern habe. Sie funktionieren nur, wenn ich sie öffentlich ansage."

Hier ist der Steam-spezifische Mechanismus, der den Cut erzwingt. Valves eigene Dokumentation:

• Deine Coming-Soon-Seite muss mindestens zwei Wochen vor dem Release-Datum live sein. (Steam Coming Soon Docs, abgerufen 2026-04-23)
• Das Release-Datum wird zwei Wochen vor Launch fest verdrahtet. Innerhalb dieses Fensters kannst du es nicht mehr ändern. (Steam Release Dates Docs, abgerufen 2026-04-23)
• Steam Review dauert mindestens sieben Werktage, bevor die Seite live gehen darf.

Rechne das mal aus. Der Moment, in dem du zur Steam-Review einreichst, liegt ungefähr drei Wochen vor einem festgenagelten Release-Datum, egal wie weit deine Polish-Liste ist. Genau das ist der Punkt.

Wie das "Datum ansagen" in der Praxis aussieht:

• Reiche deine Coming-Soon-Seite zur Steam-Review ein.
• Mail oder DM deinen Testern das Datum in der Betreffzeile.
• Sag's deinem Komponisten, deinem Marketing-Partner, allen, deren Job anfängt, wenn deiner endet.
• Pack das Datum in deinen eigenen Kalender in einer Farbe, die du nicht ignorieren kannst.

Du darfst das Datum nicht privat ansagen und dann so tun, als ob das zählt. Ein Datum, das nur in deinem Notion lebt, ändert dein Verhalten nicht. Ein Datum auf deiner Steam-Store-Seite schon.

5. Zieh deine Polish-Cut-Line: was shippt, was auf Patch 1.1 wartet

Öffne eine Tabelle mit drei Spalten: Shippt jetzt. Patch 1.1. Nachfolger oder DLC. Sortier jeden Punkt deiner Polish-Liste in genau eine Spalte.

Die Tiebreaker-Heuristik: alles, was nicht Crash-Rate, Tutorial, Core Loop oder Content-Untergrenze ändert, geht in 1.1. Punkt. Das ist ein Ein-Regel-Filter, und beim ersten Mal wird es sich brutal anfühlen.

Jason Schreiers Blood, Sweat, and Pixels verfolgt zehn veröffentlichte Spiele und findet am Ende von jedem dasselbe: eine monatelange Endphase, in der der Scope auf das zusammenfällt, was wirklich shippt, und der Rest wartet. Auch Stardew Valley. Auch Destiny. Dein Spiel ist nicht die Ausnahme, bei der das Endspiel anders läuft.

Greg Kasavin von Supergiant hat eine leicht andere Version derselben Pointe. Hades hat 1,5 Jahre in Early Access verbracht, weil das Team laut ihm nicht vorher wissen konnte, wo die Probleme und Chancen liegen. Die Community hat ihnen gesagt, wann es fertig war.

Übersetzt für Solo-Devs: das Feedback, das dir sagt, dass du fertig bist, muss nicht von einer Million Spielern kommen. Es reicht von fünf ehrlichen, die Tor 1 bis 5 durchgespielt haben, ohne dass du im Raum warst.

6. Häng eine:n Mitwirkende:n mit rein: der strukturelle Fix

Das ist der Schritt, der alle anderen Schritte tatsächlich passieren lässt. Polish wird zum Versteck, wenn niemand auf dein Release-Datum wartet. Accountability ist der eigentliche Deadline-Motor.

Tim Ruswick betreibt eine kollaborative Struktur namens DevPods. Elf oder zwölf Spiele released in zwölf Monaten. 100 Prozent pünktliche Lieferung. Der Mechanismus ist nicht Motivation. Der Mechanismus ist: der nächste Move von jemand anderem hängt von deinem Release-Datum ab.

Klau dir diesen Mechanismus. Drei Pact-Skripte mit Mitwirkenden, such dir die passenden aus:

• Komponist-Commit. "Mein Mastering-Termin ist für [Datum] gebucht. Ich brauche den Final Cut bis dahin, sonst verliere ich den Slot."
• Marketing-Partner-Commit. "Ich pitche die Presse in der Woche vom [Datum]. Wenn der Build nicht am Freitag vorher gold ist, fällt der Pitch flach."
• Porting-Partner-Commit. "Ich fange den Switch-Build am [Datum] an. Mein Zeitfenster ist fix. Wenn der PC-Build rutscht, rutscht der Port, und mein Gehalt auch."

Achte darauf, was alle drei gemeinsam haben. Die Arbeit von jemand anderem fängt an, wenn deine fertig ist. Deren Termine sind nicht verhandelbar. Deiner ist gerade auch nicht mehr verhandelbar.

Wenn du keinen Komponisten, keinen Marketing-Partner, keinen Porting-Partner hast, ist das der Schritt, an dem du einen findest. Das ist auch genau das Problem, das Clowdr löst. Du musst kein Studio aufbauen, um die Accountability eines Studios zu bekommen. Du brauchst nur Mitwirkende, deren nächster Move anfängt, wenn du shippst.

7. Umgang mit der Last-Mile-Trauer: ship, patchen, weiterziehen

Niemand schreibt darüber, was in den 48 Stunden nach Release passiert. Hier, was passiert. Du wirst dich komisch fühlen. Wahrscheinlich fühlst du dich an Tag eins nicht stolz. Du fühlst dich vielleicht, wie ein Indie-Dev es auf ResetEra nach seinem Release dokumentiert hat, betrunken, während du zuschaust, wie ein Streamer einen Crash auslöst, von dem du geschworen hast, dass er gepatcht war.

Derek Yu, nochmal:

"Das Release eines Spiels ist auch der Moment des Urteils und der Abrechnung. Viele Entwickler erleben nach dem Release ein Gefühl von Verlust und Ziellosigkeit."

Plan dafür. Schreib dir einen Patch-Plan, der an Tag 3 ausgeführt wird, nicht an Tag 0, damit du nicht panisch patchst, während deine Fans spielen. Was in den ersten 48 Stunden passiert:

• Tag 1: Crash-Telemetrie und Steam-Reviews beobachten. Noch nicht reagieren. Noch nicht patchen. Alles notieren.
• Tag 2: schlafen. Was essen. Einmal auf die Reviews schauen. Hier ist der Impuls, die Projektdatei wieder aufzumachen, am stärksten. Nicht tun.
• Tag 3: die echten Probleme triagieren. Die patchen, die Tor 1 oder Tor 2 getroffen haben. Den Rest auf die 1.1-Liste packen, die du schon gebaut hast.

Das eine, was du nicht tust: anfangen, den Code neu zu schreiben, den du geshippt hast, weil "das ist messy". Ein Postmortem auf Game Developer bringt den Impuls scharf auf den Punkt:

"'Dieser Code ist unordentlich, ich werde ihn nochmal sauber neu schreiben' ist, als würdest du dir eine Schrotflinte an den Kopf halten."

Ship, patchen, weiterziehen. Dein nächstes Wachstum passiert im nächsten Spiel, nicht im Refactor von dem, das du gerade released hast.

Häufige Fallen

• Iteration mit Polish verwechseln. Iteration ändert, was das Spiel ist. Polish verfeinert, was es bereits ist. Wenn du noch änderst, was das Spiel ist, bist du nicht in der letzten Meile. Du bist in der mittleren Meile und verkleidet dich.
• Die letzten 10 Prozent als einen einzigen Sprint behandeln. Es sind zehn Sprints. Budgetiere entsprechend. Die Ninety-Ninety-Rule ist kein Witz. Sie ist dokumentiert, datiert und Tom Cargill in den Bell Labs zugeschrieben und sie gilt für dein Spiel.
• Intern ansagen, aber nicht extern. Siehe oben. Das ist mit Abstand der häufigste Fehlermodus. Ein Datum, das nur du sehen kannst, ist kein Datum.
• Wunschlisten-Ziele als verschiebbare Cut-Line benutzen. "Ich shippe, wenn ich 10.000 Wishlists habe" ist eine Entscheidung, die du an Fremde auslagerst, die deine Burn-Rate nicht kennen. Setz das Datum auf Kalender-Mechanik, nicht auf Crowd-Vibes.

Was du als Nächstes machst

Lauf die fünf Tore diese Woche durch. Wenn mehr als ein Tor durchfällt, ist das ein echtes Signal zu deinem Scope, und unser Guide, wie du Features cuttest, bevor sie dich cutten ist dein nächster Stopp. Wenn die Tore bestehen, der Polish-Stapel sich aber trotzdem unendlich anfühlt, hat der Ninety-Ninety-Rule Guide eine wöchentliche Kadenz, die für die letzte Meile gebaut ist. Wenn du noch früher dran bist und immer noch herausfindest, wie du überhaupt bei "fast fertig" gelandet bist, ist der Complete Guide zum Fertigstellen deines Indie-Spiels der Hub, den du willst.

Was dieser Guide nicht für dich machen kann: dir eine:n Mitwirkende:n in die Sache reinhängen. Das ist strukturell, nicht motivational. Melde dich bei Clowdr an und finde den Komponisten, Marketer oder Porting-Partner, dessen nächster Move anfängt, wenn du shippst. Das Datum auf deiner Steam-Seite ist dein Problem. Jemand zu finden, der will, dass du es triffst, ist unseres.