Wenn aus einem Produkt zwei werden: So teilst du deine mit KI gebaute App, ohne von vorn anzufangen

Du hast mit einer Idee angefangen. Du hast sie deinem KI-App-Builder beschrieben, zugesehen, wie er die Screens generierte, die rauen Kanten geglättet und etwas Echtes ausgeliefert. Leute fingen an, es zu nutzen. Und dann zeigte sich, erst langsam, ein Muster im Feedback: Die Hälfte deiner Nutzer:innen wollte eine Sache, die andere Hälfte etwas anderes. Sie stritten nicht um dasselbe Feature. Sie fragten nach zwei verschiedenen Produkten.

Das ist der Moment, in dem viele Gründer:innen in Panik geraten und ein zweites Projekt von Grund auf starten. Sollten sie nicht. Es gibt einen saubereren Weg, eine KI-App zu teilen, wenn sich dein eines Produkt als zwei herausstellt — und meist bewahrt er das meiste von dem, was du schon gebaut hast. In diesem Beitrag geht es darum, wie du den Split erkennst, wann du ihn machst und welche drei Formen er tendenziell annimmt.

Wie du herausfindest, dass du zwei Produkte hast

Das Signal sieht fast nie wie ein Feature-Wunsch aus. Es sieht aus wie Reibung.

Eine Produktivitäts-App, die ich dabei beobachtet habe, hatte eine klare Geschichte. Sie wurde als “persönlicher Planer” verkauft. Nutzer:innen tauchten in zwei Ausprägungen auf. Eine Gruppe nutzte sie, um ihre eigene Woche zu planen, und behandelte sie wie ein privates Notizbuch. Die andere Gruppe leitete kleine Teams und wollte Dinge an andere zuweisen. Beide waren zufrieden genug, um dasselbe Produkt weiterzunutzen, aber jedes Release erfreute die eine Gruppe und verärgerte die andere. Das Team dachte, es habe ein Problem mit der Feature-Priorisierung. Tatsächlich hatte es ein Marken-Problem. Es hatte eine persönliche App und eine Team-App, die sich eine Codebasis, eine Startseite und eine Preisseite teilten.

Du weißt, dass du diese Linie überschritten hast, wenn eines davon zutrifft:

Deine Landingpage muss ihren eigentlichen Pitch hinter generischer Sprache vergraben, weil zwei Zielgruppen nicht denselben Worten glauben.
Jedes neue Feature kommt mit einem “aber für die andere Sorte Nutzer:in sollte es anders funktionieren”-Vorbehalt.
Deine Support-Antworten fangen an, sich zu verzweigen: “wenn du es für dich selbst nutzt …” vs. “wenn du ein Team führst …”.
Eine nicht unerhebliche Zahl von Nutzer:innen führt zwei getrennte Konten, um die beiden Modi auseinanderzuhalten.

Wenn du zwei oder mehr davon siehst, hast du kein Feature-Problem. Du hast einen Produkt-Split, der nur darauf wartet zu passieren.

Die drei Formen eines Splits

Du musst dich nicht am ersten Tag für eine Form entscheiden. Meist kannst du erst die leichteste ausprobieren und dann eskalieren. Aber es ist nützlich, das Menü zu kennen, bevor du es deinem KI-Builder beschreibst, denn die Worte, die du verwendest, prägen, was generiert wird.

Form 1: Eine App, zwei Türen

Die leichteste Version. Du behältst eine Codebasis. Du fügst beim ersten Start eine Frage hinzu — “Bist du für dich selbst hier oder für ein Team?” — und nutzt die Antwort, um einen anderen Satz Seiten und eine andere Navigation zu zeigen. Gleicher Datenspeicher. Gleicher Login. Gleiche Abrechnung. Nur eine andere Oberfläche.

Die meisten KI-App-Builder kommen damit gut klar, wenn du es als “App mit zwei Modi” beschreibst. Worauf du achten solltest: Die zwei Modi sollten sich nicht überall Screens mit bedingten Ein- und Ausblendungen teilen. Das endet so, dass es aussieht wie eine überladene App, die vorgibt, zwei zu sein. Sag dem Builder, dass die zwei Türen getrennt sind — andere Startseiten, andere Einstellungsseiten, andere Leerzustände. Die wenigen Screens, die sich tatsächlich überschneiden (Kontoeinstellungen, Abrechnung), können geteilt werden.

Wann das funktioniert: wenn die zwei Zielgruppen eine andere Rahmung, aber dieselben zugrunde liegenden Objekte wollen. Das Planer-versus-Team-Beispiel passt hierher. Das, was du planst, ist immer noch eine Aufgabe; nur die Regeln rund um Zuweisen, Teilen und Benachrichtigen ändern sich.

Wann das nicht funktioniert: wenn die zwei Zielgruppen völlig andere Objekte erwarten. Ein “Kundenportal” und ein “internes Admin-Tool” haben fast keine Überschneidung, selbst wenn sie aussehen, als ginge es um dasselbe Geschäft.

Form 2: Zwei Apps, ein Back-End

Die mittlere Form. Du teilst die Vorderseite des Produkts in zwei getrennte Apps — zwei URLs, zwei Landingpages, zwei Onboarding-Abläufe, zwei Preistabellen —, aber beide lesen darunter aus derselben Datenbank. Ein:e Kund:in kann auf beiden ein Konto haben. Ein:e Admin kann Daten von beiden sehen.

Genau das haben wir kürzlich in dem Unternehmen gemacht, das diesen Blog betreibt. Wir hatten eine App, die versuchte, zwei Zielgruppen zu bedienen: Entwickler:innen, die unsere Agenten-Plattform evaluierten, und Builder, die unseren KI-App-Builder nutzten. Gleiches Backend, gleiche Auth, gleiche Datenbank — aber das Front-End hatte zwei Köpfe bekommen, und die Botschaft war verwirrt. Wir haben es in zwei Front-End-Apps geteilt, eine für jede Zielgruppe. Das Backend blieb exakt gleich.

Diese Form ist die richtige Antwort, wenn:

Die zwei Zielgruppen aus unterschiedlichen Gründen kaufen.
Sie von der Marketing-Botschaft der anderen Zielgruppe verwirrt oder abgeschreckt wären.
Die Daten, die ihnen wichtig sind, größtenteils dieselbe Form haben, aber anders gerahmt werden.
Du nicht zwei Datenbanken oder zwei Abrechnungssysteme pflegen willst.

Sag deinem KI-Builder, dass du eine “zweite Front-End-App willst, die sich die bestehende API teilt”. Die meisten modernen KI-Builder können ein Schwesterprojekt aufsetzen und es auf dein bestehendes Backend zeigen lassen. Die Falle, die du vermeiden solltest: die Komponenten der ersten App wortwörtlich zu kopieren und dann für immer beide Kopien zu bearbeiten. Bitte den Builder, die gemeinsamen Teile (Auth-Screens, gängige Formular-Widgets) in eine kleine Bibliothek auszulagern, die beide Apps nutzen. Das erspart dir später Monate an doppelten Korrekturen.

Form 3: Zwei Apps, zwei Back-Ends

Der schwerste Split. Du hast tatsächlich zwei Produkte. Sie teilen keine Daten, sie teilen keine Nutzer:innen, und sie sollten keine Roadmap teilen. Der richtige Zug ist, sie vollständig zu trennen: getrennte Codebasen, getrennte Datenbanken, getrennte Domains.

Das ist seltener der richtige Zug, als Leute denken. Es ist verlockend, weil es sich sauber anfühlt. Die Realität ist, dass zwei völlig getrennte Apps zwei von allem bedeuten, das am Laufen gehalten werden muss — zwei Deploy-Pipelines, zwei Bereitschaftsdienste, zwei Abrechnungs-Integrationen, zwei Hilfe-Dokus. Greif zu dieser Form nur, wenn sich die Produkte wirklich nicht überschneiden. Ein guter Test: Wenn ein:e Nutzer:in von Produkt A niemals ein:e Nutzer:in von Produkt B wäre, brauchst du wahrscheinlich Form 3. Wenn die meisten deiner Nutzer:innen plausibel beides wollen könnten, willst du fast sicher Form 2.

Wenn du das mit einem KI-Builder machst, ist der einfachste Zug, dein bestehendes Projekt als Startpunkt für das zweite zu kopieren und den Builder dann zu bitten, die Features zu entfernen, die nicht dorthin gehören, und die hinzuzufügen, die dorthin gehören. Starte das zweite Projekt nicht von einer leeren Leinwand. Du hast beim Bauen des ersten schon viel gelernt, und der KI-Builder greift diesen Kontext auf, wenn du ihn lässt.

Was du tun solltest, bevor du irgendetwas teilst

Bevor du den Split deinem KI-Builder beschreibst, mach drei kleine Dinge. Sie sind mehr wert, als sie klingen.

Erstens: Schreib die neue Startseite für jede Seite. Je zwei Absätze. Der Pitch, die Zielgruppe, das eine, was du willst, dass sie tun. Wenn du nicht zwei verschiedene Startseiten schreiben kannst, hast du noch nicht wirklich zwei Produkte — du hast nur zwei Segmente eines Produkts, und das solltest du mit Botschaft lösen, nicht mit Architektur.

Zweitens: Liste auf, welche Screens geteilt werden und welche nicht. Sei ehrlich. “Login ist geteilt. Onboarding ist anders. Dashboard ist anders. Einstellungen sind größtenteils geteilt. Abrechnung ist geteilt.” Diese Liste wird zum Briefing, das du dem KI-Builder gibst. Sie spart eine Menge Hin und Her.

Drittens: Entscheide, was darunter gleich ist. Gleiche Nutzer:innen? Gleiche Daten? Gleiche Zahlungen? Jedes “Ja” zieht dich zu Form 1 oder 2. Jedes “Nein” zieht dich zu Form 3. Es gibt keine richtige Antwort — nur die Antwort, die dazu passt, wie dein Produkt tatsächlich funktioniert.

Was sich nach dem Split ändert

Zwei Dinge werden leichter und ein Ding wird schwerer.

Marketing wird leichter. Jede App bekommt ihren eigenen klaren Pitch. Jede Landingpage kann eine Zielgruppe ansprechen, ohne sich abzusichern. Deine Conversion-Rate steigt meist auf mindestens einer Seite, manchmal auf beiden.

Onboarding wird leichter. Ein:e Erstnutzer:in landet auf einer Seite, in der es um sie oder ihn geht, nicht auf einer Seite, die versucht, für alle da zu sein.

Was schwerer wird, ist, die gemeinsamen Teile synchron zu halten. Wenn du einen Bug im Login-Ablauf behebst, willst du ihn in beiden Apps behoben haben. Wenn du änderst, wie der Abrechnungs-Screen aussieht, willst du, dass beide Apps das widerspiegeln. Die Disziplin, die du brauchst — und das gilt, egal ob du mit einem KI-Builder Vibe Coding betreibst oder mit einem Team menschlicher Entwickler:innen baust —, ist, die gemeinsamen Teile wirklich gemeinsam zu halten. Nicht duplizieren. Nicht forken. Lager entweder den gemeinsamen Screen in eine kleine Bibliothek aus, die beide Apps nutzen, oder akzeptiere, dass du zwei wirklich getrennte Apps hast, und steh dazu.

Eine kleine Frage zum Schluss

Wenn du den Pitch deiner aktuellen App fünf fremden Personen vorlegst und jede ihn anders beschreibt — aber in zwei deutlich getrennten Schubladen —, lebst du wahrscheinlich schon mit dem Split. Die einzige Frage ist, ob du weiter die Steuer eines verwirrten Produkts zahlst oder die Arbeit machst, ehrlich zuzugeben, dass es zwei sind.

Du musst dich heute nicht entscheiden. Aber das nächste Mal, wenn dein KI-App-Builder fragt “was soll ich als Nächstes bauen?”, bedenke, dass die nützlichste Antwort vielleicht kein neues Feature ist. Es könnte eine neue Eingangstür sein.

Wenn dich das angesprochen hat, gefällt dir vielleicht auch unser früherer Beitrag über bauen für dein Team vs. bauen für Kund:innen — dieselbe Art von Entscheidung, einen Schritt früher im Leben deines Produkts.