Der Prototyp vs. das Produkt: So erkennst du, wann deine KI-gebaute App wirklich fertig ist

Vor ein paar Wochen hat eine Gründerin, die ich kenne, eine Terminplanungs-App für Therapeut:innen gebaut. Das Ganze hat sie mit einem KI-App-Builder vier Tage gekostet. Sie macht, was sie braucht: Therapeut:innen sehen ihren Kalender, Klient:innen buchen Termine, Bestätigungen gehen per E-Mail raus. Es funktioniert.

Sie starrt es seit zwei Wochen an und hat nicht gelauncht.

Als ich fragte warum, sagte sie: “Es funktioniert, aber… es fühlt sich nicht fertig an.”

Ich fragte sie, was sie ändern würde. Sie sagte: “Ich weiß es nicht. Das ist das Problem.”

Das ist der schwerste Moment beim Bauen mit einem KI-App-Builder. Das Ding ist funktional, aber es gibt eine Lücke zwischen “funktional” und “ich würde mich wohlfühlen, echte Menschen darum zu bitten, das zu nutzen”. Diese Lücke zu verstehen — und zu wissen, auf welcher Seite davon man wirklich steht — ist der Unterschied zwischen Ausliefern und für immer in der Stimme-im-Kopf-Phase stecken zu bleiben.

Was “fertig” wirklich bedeutet

Hier ist die Unterscheidung, auf die es ankommt: Ein Prototyp ist etwas, mit dem du eine Idee testest. Ein Produkt ist etwas, mit dem du ein Problem löst.

Die Terminplanungs-App für Therapeut:innen ist ein Prototyp. Sie beweist, dass das Konzept funktioniert. Ein:e Therapeut:in könnte sie nutzen. Aber es gibt siebzehn Kleinigkeiten, die sie roh wirken lassen:

Die E-Mail-Bestätigungen sind nackt. Kein Logo, kein eigenes Branding, generischer Text.
Absagen lösen keine Benachrichtigungen aus. Klient:innen erscheinen einfach nicht.
Es gibt keine Warteliste, wenn ein:e Therapeut:in ausgebucht ist.
Der Anmeldeablauf erfasst nicht die Spezialgebiete des/der Therapeut:in, also gibt es keine Möglichkeit, nach Praxisart zu filtern.
Es gibt keine Erinnerungs-E-Mail, die 24 Stunden vor dem Termin gesendet wird.

Nichts davon macht die App kaputt. Alles davon lässt eine:n echte:n Therapeut:in denken: “Das fühlt sich nach etwas an, das jemand an einem Wochenende zusammengeschustert hat, nicht nach etwas, wofür man mir Geld berechnet.”

Dieses Gefühl ist real, und es zählt. Ein Prototyp löst das Problem in der Theorie. Ein Produkt löst es in der Praxis, für den tatsächlichen Menschen, der es nutzt.

Drei Fragen, die Prototyp von Produkt trennen

Hier ist der schwierige Teil: Du kannst nicht alles wissen, was fehlt. Dein KI-Builder kann es auch nicht wissen. Also brauchst du drei schnelle Fragen, um herauszufinden, auf welcher Seite der Linie du stehst.

1. Würdest du das nutzen, um dein eigenes Problem zu lösen?

Diese ist ehrlich, weil du tatsächlich mit deinem eigenen Produkt leben musst.

Wenn du die Gründerin dieser Terminplanungs-App für Therapeut:innen bist — würdest du sie nutzen, um deine eigenen Therapietermine zu planen? Nicht “könntest du” — würdest du sie tatsächlich nutzen statt eines E-Mail-Verlaufs oder eines geteilten Google Docs?

Wenn die Antwort Nein ist, bist du nicht fertig. Du weißt genau, was nicht stimmt — du spürst es jedes Mal, wenn du die App öffnest. Wenn die Antwort Ja ist, bist du näher dran.

Die erwähnte Gründerin ging durch ihre eigene Therapeuten-Anmeldung. Sie blieb am Formular hängen (es fragte zu viele Informationen ab, bevor es sie buchen ließ). Sie sah die Bestätigungsmail und fand sie amateurhaft. Sie fing an, darüber nachzudenken, wie ihre Therapeutin die E-Mail empfangen würde und ob sie im Spam landen würde.

Sie nutzte ihr eigenes Produkt nicht so, wie es ein:e zahlende:r Kund:in tun würde. Als sie es tat, fand sie zehn Dinge zum Reparieren.

2. Hast du es drei Menschen gezeigt, die nicht du sind?

Mit potenziellen Nutzer:innen zu reden ist schwerer als zu bauen, und die meisten Gründer:innen überspringen es, weil sie die Leute beim Launch überraschen wollen. Das ist ein Fehler.

Du brauchst keine Fokusgruppe. Du brauchst drei Menschen, die deiner Vorstellung von deiner Kundschaft ähneln. Für die Therapeuten-App sind das drei echte Therapeut:innen.

Hier ist, worauf du achtest: Wo werden sie verwirrt? Wo zögern sie? Was fragen sie? Nicht “Was halten sie davon?” (Menschen sind zu nett.) Bitte sie, die Sache tatsächlich zu tun — einen Termin buchen, eine Bestätigungsmail verschicken, etwas absagen.

Als die Gründerin ihre Therapeuten-App drei Therapeut:innen zeigte, fragten zwei: “Kann ich Regeln festlegen, wann ich verfügbar bin? Etwa: Ich nehme neue Klient:innen nur donnerstags und doppelbelege nicht vor 14 Uhr.” Die App hatte einen Kalender, aber keine Regeln. Sie hatte den Prototyp dafür gebaut, wie sie dachte, dass Terminplanung funktioniert, nicht dafür, wie Therapeut:innen tatsächlich arbeiten.

Das ist Produktinformation. Das hättest du aus keiner Spezifikation erraten können.

3. Was würde kaputtgehen, wenn du das zehn echten Nutzer:innen gäbest?

Das ist die schwerste Frage, weil sie verlangt, dass du wirklich über deine Randfälle nachdenkst.

Für die Therapeuten-App:

Was passiert, wenn ein:e Klient:in versucht, zwei Termine zur gleichen Zeit zu buchen? (Die App prüft das nicht.)
Was passiert, wenn ein:e Therapeut:in einen Termin absagt? Werden Klient:innen automatisch benachrichtigt? (Nein.)
Was, wenn die E-Mail-Adresse eines/einer Klient:in falsch ist? Gibt es eine Möglichkeit, sie zu korrigieren, ohne von vorn anzufangen? (Nein.)
Was, wenn ein:e Therapeut:in einen Krankheitstag hat und ihren Kalender für eine Woche schließen muss? (Sie müsste jeden Termin manuell löschen.)

Das sind keine Bugs. Die App stürzt nicht ab. Aber es sind Papierschnitte. Mit zehn echten Nutzer:innen und echten Randfällen triffst du in der ersten Woche auf alle.

Ein Produkt handhabt die Randfälle. Nicht alle — manche Dinge können warten. Aber die, die in den ersten zwei Wochen mit echten Nutzer:innen auftreten, die müssen funktionieren.

Wie du dich entscheidest: der Drei-Schichten-Test

Nutze das, um herauszufinden, wo du stehst:

Schicht 1: Kern-Flow — Funktioniert der Happy Path? Kann ein:e Nutzer:in die Hauptsache tun, für die deine App gedacht ist?

Für den Therapeuten-Planer: ja. Jemand kann sich anmelden, einen Termin buchen, eine Bestätigung erhalten. Es funktioniert.

Schicht 2: Randfälle aus echter Nutzung — Du hast es drei echten Nutzer:innen gezeigt. Sind sie auf etwas gestoßen, das du nicht gebaut hast? Waren sie irgendwo verwirrt?

Für den Therapeuten-Planer: ja. Die drei Therapeut:innen wollten regelbasierte Verfügbarkeit. Eine:r war verwirrt, weil die E-Mail-Bestätigung zu generisch aussah. Eine:r versuchte, Termine massenweise zu löschen, und konnte es nicht.

Schicht 3: Feinschliff und Professionalität — Fühlt es sich an, als ob es dir wichtig ist? Oder fühlt es sich an, als hättest du es zusammengeschustert?

Für den Therapeuten-Planer: Es fühlt sich zusammengeschustert an. Die E-Mail-Bestätigungen sind nackt. Es gibt kein eigenes Branding. Es gibt keine Fehlermeldung, wenn etwas schiefgeht, also hat der/die Nutzer:in, wenn etwas kaputtgeht, keine Ahnung, was passiert ist.

Hier ist die Faustregel:

Alle drei Schichten funktionieren? Du bist ein Produkt. Liefere aus.
Schichten 1 und 2, aber nicht 3? Du bist zu 80 % fertig. Verbring einen Tag mit dem Feinschliff.
Schicht 1 funktioniert, Schichten 2 und 3 nicht? Du bist ein Prototyp. Liefere noch nicht aus.
Schicht 1 ist nicht solide? Du bist nicht fertig. Bau weiter.

Die Therapeuten-App steckte an der Grenze zwischen Schicht 1 und Schicht 2 fest. Der Kern-Flow funktionierte, aber echte Therapeut:innen fanden, dass Teile fehlten. Also hatte die Gründerin eine Wahl: noch eine Woche mit ihrem KI-Builder verbringen und die Features hinzufügen, die Therapeut:innen wirklich brauchen, oder mit dem launchen, was sie hatte, und sie später ergänzen.

(Sie fügte sie hinzu. Es dauerte drei Tage. Jetzt ist es ein Produkt.)

Das, was das schwer macht

Der Grund, warum so viele Gründer:innen hier feststecken, ist, dass Bauen Spaß macht und Ausliefern Angst macht.

Bauen ist ein Gespräch mit deinem KI-Tool. Du hast eine Idee, du beschreibst sie, das Tool führt sie aus. Es gibt eine Feedback-Schleife, die Minuten dauert. Ausliefern ist anders. Du klickst auf Veröffentlichen, und wenn etwas falsch ist, finden es echte Menschen heraus. Es gibt kein zweites Mal.

Also finden wir Gründe, nicht auszuliefern. “Es ist nicht poliert genug.” “Ich sollte noch ein Feature hinzufügen.” “Was, wenn die Schriften falsch sind?” Und sechs Wochen später sitzt du immer noch auf etwas, das funktioniert, sich aber nicht fertig anfühlt, und du hast dir eingeredet, es liege an den Schriften.

Es liegt nicht an den Schriften.

Es liegt meist daran, dass du keine Zeit mit echten Nutzer:innen verbracht hast oder etwas gebaut hast, das in deinem Kopf Sinn ergab, aber nicht ganz dazu passt, wie echte Menschen arbeiten. Das ist behebbar. Es erfordert nur einzugestehen, dass du nicht weißt, was du nicht weißt, und dann mit jemandem zu reden, der es weiß.

Die Launch-Readiness-Checkliste

Nutze das. Sie ist kurz und ehrlich.

Ich habe sie selbst genutzt, um die echte Aufgabe zu erledigen, und es hat funktioniert (nicht im Demo-Modus, sondern tatsächlich).
Ich habe sie drei Menschen gezeigt, die sie wirklich nutzen würden, und ich habe die Dinge behoben, über die sie verwirrt waren.
Jeder Fehler, der auftreten kann, hat eine Meldung, die dem/der Nutzer:in sagt, was zu tun ist (nicht “Fehler”, sondern echte Anleitung).
Es wäre okay für mich, wenn das für sechs Monate die letzte Version wäre (heißt: Es ist vollständig genug, um nützlich zu sein, selbst wenn ich es nie wieder anfasse).
Ich bin gespannter darauf, was ich von echten Nutzer:innen lerne, als darauf, im luftleeren Raum weitere Features hinzuzufügen.

Wenn du alle fünf Kästchen ankreuzen kannst, bist du fertig. Launch.

Wenn nicht, dann nicht. Aber sei konkret, warum. “Es fühlt sich nicht fertig an” ist kein Grund. “Echte Therapeut:innen brauchen Verfügbarkeitsregeln, und die habe ich noch nicht gebaut” ist ein Grund. Das ist umsetzbar. Das ist behebbar. Das ist der Unterschied zwischen feststecken und auf einem Weg sein.

Die Gründerin der Therapeuten-App hat sie gestern ausgeliefert. Sie hat ihre erste zahlende Kundin. Das Produkt ist nicht perfekt, aber es ist echt, und ihre Kundin sagt ihr schon, was als Nächstes zu bauen ist. Daran erkennst du, dass du fertig bist: nicht wenn die App perfekt ist, sondern wenn du bereit bist zu lernen, was perfekt für die Menschen, die sie nutzen, wirklich bedeutet.