Ich habe schon dabei zugesehen, wie drei verschiedene Menschen denselben dreißigsekündigen Screen falsch gehandhabt haben — die Plankarte, die zwischen deinem Prompt und dem Build erscheint —, und jeder hat dafür auf seine eigene Art bezahlt. Der eine mit einem kompletten Neubau. Der andere mit vertaner Tipparbeit. Und der dritte mit einem Produkt, das das eigentlich Benötigte nicht konnte. Die Plankarte ist der günstigste Moment im gesamten Prozess, um seine Meinung zu ändern, und gerade das macht es so leicht, achtlos daran vorbeizugehen.
Fehler eins: einfach abnicken
Das ist der häufigste Fehler. Skelett sieht richtig aus, auf „Genehmigen“ klicken, weitermachen — das habe ich selbst wochenlang so gemacht, bis es mich eingeholt hat. Der Build, der die Angewohnheit endgültig beendet hat, kam mit einer Stripe-Kasse zurück, die in eine statische Website eingebaut war, die schlicht keinen Platz für den Kontostatus hatte, den Stripe benötigte. In der Plankarte stand ganz einfach Produkttyp: statische Website, direkt sichtbar — ich bin einfach daran vorbeigescrollt, weil die Seitenliste in Ordnung aussah und ich es eilig hatte.
Der Schaden durch diesen Fehler sieht immer gleich aus: Alles, was auf den Plan folgt, ist korrekt bezogen auf den Plan — der Fehler zeigt sich also nicht als Fehlermeldung, sondern als funktionierender Build, der strukturell falsch ist. Niemand bemerkt es, weil nichts kaputt ist — eine statische Website mit Kaufen-Button macht einfach still und leise das Falsche, oder versagt genau in dem Moment, in dem ein echter Nutzer auf „Bezahlen“ klickt. Man merkt es erst im Review, und das ist der teuerste Ort, um es zu merken.
Fehler zwei: übermäßig präzise sein, um eine zweite Runde zu vermeiden
Der gegenteilige Fehler wirkt verantwortungsbewusster, ist es aber nicht. Manche Leute, einmal durch Fehler eins gebrannt, überkorrigieren und schreiben in der Planphase einen ganzen Absatz präziser Anforderungen — exakte Texte, Abstandsvorlieben, welche Funktionen unbedingt vorhanden sein sollen und welche nicht, formuliert wie ein Lastenheft. Das habe ich auch schon getan, aus einer vagen Sorge heraus, dass das Weglassen von Details jetzt bedeutet, später eine Build-Runde zu „verschwenden“.
Das ist genau verkehrt herum, und zwar aus folgendem Grund: Der Plan wird sowieso noch einmal überarbeitet, sobald man die tatsächlichen Seiten sieht — egal wie sorgfältig man beim ersten Mal war. Und wenn er überarbeitet wird, bekommt man kein Diff der Änderungen, sondern eine komplett neue Karte, die die eigene Änderung bereits eingearbeitet hat, Punkt, keine Änderungsnotizen. Die Präzision, die man in Runde eins getippt hat, überlebt also ohnehin nicht unverändert bis Runde zwei — man liest sich in jedem Fall alles noch einmal durch. Zwei oder drei Runden „nein, so ungefähr“ führen zu einem besseren Ergebnis, und das in kürzerer Zeit, als ein erschöpfendes Briefing — auch wenn sich das Schreiben des Briefings während des Tippens effizienter anfühlt.
Die einfachen Änderungswünsche, die tatsächlich funktionieren, sind kurz:
- „Blog weglassen, Preisseite hinzufügen“ — tauscht die Seitenliste sauber aus.
- „Für zwei Spieler statt für einen Spieler machen“ — größer, als es klingt. Das kann das Datenmodell betreffen, das jetzt zwei Teilnehmer statt einem verfolgt, und der überarbeitete Plan zeigt diese Auswirkung, statt sie zu verbergen.
- „Das braucht Benutzerkonten“ — wenn der aktuelle Plan eine statische Website ist, ist das der Satz, der die Frage nach dem Produkttyp unmittelbar erzwingt.
Fehler drei: den Produkttyp wie ein weiches Feld behandeln
Das ist der teure Fehler, und zwar weil alles andere auf der Karte tatsächlich reparabel ist. Seiten, abgeleitete Funktionen, die meisten Verzweigungen bei Fragen — all das lässt sich nach der Fertigstellung des Builds mit einer Versionsiteration korrigieren. Der Produkttyp nicht. Es gibt vier Kategorien:
| Produkttyp | Was das bedeutet |
|---|---|
| Statische Website | Einfach, ohne Serverlogik. |
| Installierbare App | PWA-artig — offlinefähig, kann zum Homescreen hinzugefügt werden, weiterhin keine Serverlogik. |
| Framework-Build | React/Next-artig, stärkere clientseitige Interaktivität, aber weiterhin kein dauerhaftes Backend. |
| Serverbasierte App | Der einzige der vier Typen mit echter Datenbank und Kontosystem im Hintergrund. |
Wenn man einen Plan für eine statische Website genehmigt und sich drei Versionen später für eine Anmeldefunktion entscheidet, ist das kein Versionsupdate — das ist ein Neubau mit einem anderen Produkttyp, und man verliert die Kontinuität, die einem die Versionshistorie für alles andere geboten hätte.
Hier gehen die Leute auf zwei Arten in die Falle. Erstens prüfen sie ihren eigenen Prompt nicht gegen die Realität — wenn dein Prompt „Konten“, „Login“, „speichern“, „Dashboard, das sich aktualisiert“, „Zahlungen“ oder „mehrere Nutzer bearbeiten dasselbe“ enthält und die Karte nicht „serverbasiert“ angibt, ist genau das die eine Korrektur, die sich vor der Freigabe lohnt, ohne Ausnahme. Zweitens verwechseln sie installierbare App mit Framework-Build, weil sich beide anfühlen wie „eine App“ im lockeren Sprachgebrauch. Sie sind nicht austauschbar: Installierbare App passt zu einem Tool, bei dem der gesamte Zustand auf dem Gerät des Nutzers liegt — ein Trinkgeldrechner, ein Workout-Timer. Framework-Build bedeutet mehr Interaktivität und Komponentenstruktur, aber immer noch nichts, das serverseitig über Sitzungen oder Geräte hinweg bestehen bleibt. Keines von beiden ist „eine App“ im Sinne von Konten und Daten, die dich über Geräte hinweg begleiten — nur serverbasiert ist das. Und serverbasiert „für alle Fälle“ zu überprovisionieren, für eine Portfolio-Seite oder eine Dokumentationsseite, ist ebenfalls nicht die sichere Wahl — ein späteres Herabstufen ist genauso aufwendig wie ein Upgrade es gewesen wäre.
Was übrig bleibt, wenn man diese drei Dinge nicht mehr tut
Sobald man nicht mehr über die Produkttyp-Zeile hinwegliest, in der Planphase kein Lastenheft schreibt und Sprache zu Konten, Daten oder Zahlungen im eigenen Prompt nicht als verhandelbar behandelt, bleibt eine schnelle, gezielte Prüfung übrig:
- Den Produkttyp lesen.
- Ihn mit dem eigenen Prompt abgleichen.
- Die Liste der abgeleiteten Funktionen nach allem überfliegen, das man auf den ersten Blick ablehnen würde.
Diese Liste existiert genau deshalb, weil ein Prompt wie „Terminplanungstool für Friseursalons“ Dinge mit sich zieht, die man nicht getippt hat — Kalenderansicht, SMS-Erinnerungen und eine Kundenliste, wovon man manches wollte und manches Scope Creep ist, den das Modell hinzugefügt hat, weil diese Funktionen statistisch gemeinsam auftreten. Was nicht hierher gehört, kürzt man in einem Satz, jetzt, statt nachdem es gebaut wurde.
Alles andere — Texte, Abstände, welcher Akzentfarbton, ob der Button „Loslegen“ oder „Kostenlos testen“ sagt — steht bewusst gar nicht auf der Karte. Das lässt sich an einem funktionierenden Build günstig ansehen und korrigieren, deshalb verschwendet die Karte darauf keine Aufmerksamkeit, und man selbst sollte das auch nicht tun. Das sind vielleicht fünfzehn Sekunden echter Beurteilung innerhalb der dreißig Sekunden, die man zum Lesen braucht.
