Im vorigen Kapitel haben wir festgehalten, dass Indie-Entwicklung in den fünf Phasen „entscheiden → vorbereiten → bauen → veröffentlichen → wachsen" abläuft und dass die eiserne Regel lautet: „Auf eine Funktion beschränken und ein MVP veröffentlichen." Dieses Kapitel 2 behandelt die erste Phase, „Entscheiden". Lassen Sie uns gemeinsam klein festlegen, was und für wen Sie bauen, und das bis zu einer Spezifikation (Spec) bringen.
Das, „was Sie bauen wollen", so weit fixieren, dass Sie es der KI übergeben können
Warum zuerst „entscheiden"?
Der Wunsch, sofort Code zu schreiben, ist gut nachvollziehbar. Doch der häufigste Fehler in der Indie-Entwicklung ist, „beim Bauen aus den Augen zu verlieren, was man eigentlich baut". Wer mit unklarem Ziel loslegt, verliert unterwegs die Richtung – „ach, diese Funktion auch noch" – und wird nie fertig.
Deshalb darf das Programmieren warten. Klären Sie zuerst „was, für wen und bis wohin" Sie bauen. Wer ohne Karte und Ziel losläuft, verirrt sich zwangsläufig; steht das Ziel dagegen fest, führt Sie die KI als Partner auf dem kürzesten Weg dorthin.
Funktionen wachsen und wachsen, es wird komplex. Auch die Anweisungen an die KI schwanken jedes Mal. Die Fertigstellung rückt in die Ferne, die Motivation versiegt, das Projekt bleibt liegen.
Das Ziel steht als eines fest. Sie können die KI präzise anweisen, und auch die Ausgabe schwankt nicht. Auf kürzestem Weg zum „lauffähigen Produkt".
💡 „Entscheiden" ist keine Zeit zum Grübeln. Sie brauchen kein perfektes Konzeptpapier. In diesem Kapitel treffen Sie nur kleine Entscheidungen, die auf ein DIN-A4-Blatt (oder eine Notiz-Ansicht) passen. Statt beim Grübeln stehenzubleiben, kommen Sie viel schneller ans Ziel, wenn Sie – auch vorläufig – entscheiden und weitergehen.
Ideen finden – Sparring mit der KI
„Ich habe keine besondere Idee" – kein Problem. Ideen presst man nicht aus dem Nichts, sondern hebt sie aus alltäglichen Ärgernissen. Und genau diese Ausgrabungsarbeit kann die KI am besten. Sie müssen nicht allein grübeln. Nehmen Sie die KI als Sparringspartner, dann sprudeln die Ideen nur so.
Was Sie täglich als ein wenig lästig empfinden. Wiederkehrende Handarbeit, der Aufwand des Festhaltens, die Zeit fürs Suchen. Was Sie stört, stört auch jemand anderen.
Das, wovon Sie dachten „so eine App würde ich nutzen". Der erste Nutzer sind Sie selbst. Was Sie wirklich wollen, hält die Motivation zum Bauen wach.
Werfen Sie ein vages Interesse in die KI und lassen Sie sich Rückfragen stellen. Im Gespräch werden die Umrisse sichtbar. Ideal, um Einfälle laut auszusprechen.
Der Trick beim Sparring ist, ein konkretes Thema zu werfen. „Hast du eine gute App-Idee?" bringt keine gute Antwort. Fragen Sie stattdessen mit gezieltem Blickwinkel, etwa so:
- „Nenne mir 10 App-Ideen, die das Ärgernis der Haushaltsverwaltung lösen, je in einem Satz."
- „Welche davon lässt sich am kleinsten bauen? Mit Begründung."
- „Gibt es für diese Idee wirklich Nutzer? Sag mir die Zielgruppe und die Nutzungssituation."
- „Gibt es schon ähnliche Dienste? Wenn ja, wo liegt der Unterschied, den ein Einzelner besetzen kann?"
- „Wenn ich diese Idee auf nur eine Funktion reduziere, welche sollte bleiben?"
Sich 10 vorschlagen lassen und eine auswählen – dieses Vorgehen wirkt. Die KI stellt in Sekunden viele Kandidaten nebeneinander, sodass sich Ihre Aufgabe auf das „Auswählen" konzentriert. Spricht Sie etwas an, gehen Sie damit weiter in die Tiefe.
Auf eine Funktion beschränken – die eiserne Regel
Zeichnet sich eine Idee ab, kommt es als Nächstes darauf an, „nicht zu überladen". Erinnern Sie sich an die eiserne Regel aus dem vorigen Kapitel? Auf eine Funktion beschränken und ein MVP veröffentlichen – das ist in der Indie-Entwicklung die am leichtesten gebrochene und die am strengsten zu haltende Regel.
In dem Moment, in dem Sie „wenn schon, dann auch diese und jene Funktion" gierig werden, rückt die Fertigstellung in die Ferne. Denn mit zwei Funktionen verdoppelt sich die Arbeit nicht nur, sondern wächst durch die Kombinationen auf das Drei- oder Vierfache. Zeit und Energie eines Einzelnen sind begrenzt. Beschränken Sie sich anfangs auf das eine „Wenn das gelingt, hat es Wert".
Bücher erfassen, Notizen, Sterne-Bewertung, Lesezeit-Grafik, mit Freunden teilen, KI-Buchempfehlungen, Barcode scannen … Alles-in-einem angepeilt und nie fertig.
Nur „ein gelesenes Buch mit einem einzeiligen Fazit festhalten". In einer Liste zurückblicken reicht. Erst veröffentlichen, und wenn es genutzt wird, das Nächste ergänzen.
✅ Der Maßstab zum Streichen: „Geht es ohne das nicht?" Zweifelhafte Funktionen legen Sie zunächst in die „Später"-Kiste. Nicht wegwerfen, sondern nach der Veröffentlichung ergänzen, wenn sie wirklich gebraucht werden. Läuft die erste Funktion und wird sie genutzt, sagt Ihnen die Reaktion der Nutzer, was als Nächstes dazukommt.
Die Idee in einem Satz formulieren
Die auf eine Funktion reduzierte Idee gießen Sie nun in einen Satz. Das ist der Kern dieses Kapitels. Wenn Sie das vage Bild im Kopf in die Form „für wen, welches Ärgernis, wie gelöst" pressen, wird die Idee auf einen Schlag konkret.
„Eine App für Menschen, die viel lesen, die das Ärgernis, gelesene Bücher schnell wieder zu vergessen, so löst, dass man sie mit einem einzeiligen Fazit rasch festhält und in einer Liste zurückblickt."
Wenn Sie diesen einen Satz schreiben können, ist Ihre Indie-Entwicklung schon halb geglückt. Alles Weitere – die Technikwahl, die Anweisungen an die KI, bis hin zum Vorstellungstext bei der Veröffentlichung – hält dieser Satz als unverrückbare Achse zusammen. Gelingt er nicht auf Anhieb, lassen Sie sich auch dabei von der KI helfen. Bitten Sie „Fasse diese Funktion in einem Satz nach ‚für wen, welches Ärgernis, wie gelöst'", und sie liefert gleich mehrere Vorschläge.
Zur Spezifikation machen – das Fundament der KI-Entwicklung
Steht der eine Satz, machen Sie daraus zum Schluss eine Spezifikation (Spec). Eine Spezifikation ist eine „Konstruktionsnotiz dazu, was gebaut wird". Denken Sie nicht kompliziert; es genügt, die drei Punkte Screens, Daten und Aktionen minimal aufzuschreiben.
Warum die Spezifikation wichtig ist? Weil beim KI-Coding die Spezifikation direkt zum Fundament wird. Statt „bau mir so eine App" hinzuwerfen, bekommen Sie um ein Vielfaches genaueren Code, wenn Sie eine Spezifikation mit Screens, Daten und Aktionen übergeben. Zu Ende gedacht ist das die spezifikationsgetriebene Entwicklung (Spec-Driven Development), und dasselbe Prinzip wirkt auch in der Indie-Entwicklung.
Welche Screens es braucht.
Beispiel: Eintragsliste, Eintrag hinzufügen. Meist reichen 2 bis 3 Screens.
Was gespeichert wird.
Beispiel: Buchtitel, Fazit, Datum. Einfach die Felder als Stichpunkte.
Was der Nutzer tun kann.
Beispiel: Eintrag hinzufügen, in Liste ansehen. Das Mögliche als Verben auflisten.
Was Sie zu diesen drei Punkten aufschreiben, ist Ihre erste Spezifikation. Für eine Lese-Tagebuch-App etwa wird daraus folgende Notiz.
Daten: Buchtitel (Text) / Fazit (einzeiliger Text) / Datum (Datum)
Aktionen: Eintrag hinzufügen, Liste nach Neuestem sortiert ansehen, Eintrag löschen
💡 Die Spezifikation muss nicht perfekt sein. Sie müssen nicht von Anfang an alles fertig aufschreiben. Merken Sie beim Bauen „ah, das brauche ich auch", ergänzen Sie es einfach. Wichtig ist, „erst einmal ein Blatt als Fundament zu haben". Mit einem Entwurf kommen KI und Mensch um ein Vielfaches schneller voran als aus dem Weißen heraus.
Vorgehen auf Einsteiger- und Praxis-Route
Die bisherige „Entscheiden"-Arbeit ist auf beiden Routen gleich. Anders ist nur, wie formal Sie die Spezifikation schreiben und wem Sie sie übergeben. Gehen Sie passend zu Ihrer Route vor.
Die Spezifikation darf handschriftlich im Notizblock oder Heft sein. Ein sauberes Dokument braucht es nicht. Haben Sie „Screens, Daten, Aktionen" als Stichpunkte, fügen Sie sie direkt in den KI-Chat ein und machen Sparring. Fragen Sie „Fehlt etwas oder widerspricht sich etwas in dieser Spezifikation?", und die KI füllt die Lücken.
Ziel dieses Kapitels: Wenn der eine Satz und die Drei-Punkte-Notiz stehen, ist alles gut.
Fassen Sie die Spezifikation in einer Markdown-Datei (z. B. spec.md) zusammen und geben Sie sie an Claude Code oder Cursor. Der KI-Editor liest die Spezifikation als Fundament der Umsetzung – je sorgfältiger hier, desto schneller danach. Zum Schreiben hilft die spezifikationsgetriebene Entwicklung.
Ziel dieses Kapitels: Wenn eine spec.md steht, die Sie dem KI-Editor geben können, ist alles gut.
Auf beiden Routen gilt: Am Ende dieses Kapitels haben Sie „die Ein-Satz-Formulierung" und „die Minimalspezifikation aus Screens, Daten und Aktionen" in der Hand – das ist das Ziel. So weit gekommen, müssen Sie nur noch das Fundament zum Bauen legen. Sie sind bereit für die nächste Phase.
Zusammenfassung und nächstes Kapitel
- Programmieren kann warten. Wer zuerst „was und für wen" entscheidet, verirrt sich nicht.
- Ideen kommen aus alltäglichen Ärgernissen und dem, was Sie selbst wollen. Sparring mit der KI: 10 vorschlagen lassen, eine wählen.
- Die eiserne Regel der Indie-Entwicklung: „Auf eine Funktion beschränken". Zweifelhaftes in die „Später"-Kiste.
- Die Idee in einen Satz „für wen, welches Ärgernis, wie gelöst" formulieren.
- Die Spezifikation umfasst minimal Screens, Daten, Aktionen. Beim KI-Coding ist die Spezifikation das Fundament.
- Einsteiger arbeiten mit Notizblock und KI-Chat, die Praxis mit einer spec.md in Markdown.
Die Phase „Entscheiden" endet hier. Ist die Idee ein Satz und liegt die Minimalspezifikation vor, sind Sie nur einen Schritt vom Losbauen entfernt. Als Nächstes entscheiden Sie, mit welcher Technik und welchen Werkzeugen Sie es tatsächlich bauen. Sie dürfen zum vorigen Kapitel 1 „Das Ganze und die Routenwahl" zurückkehren, um die Landkarte noch einmal anzusehen, oder gleich zum Kapitel 3 „Technik und Werkzeuge vorbereiten" weitergehen. Der Bau des Fundaments, das Ihren einen Satz Wirklichkeit werden lässt, beginnt.