KI-MVP im SaaS: Was bauen Sie zuerst bei festem Budget?

Im vergangenen Jahr kam ein Gründer mit einer Liste von zweiundzwanzig Funktionen zu uns. Sein Pitchdeck versprach sie alle, und er hatte noch neun Monate Geld. Die Liste war gut, das Problem war die Reihenfolge. Sechs dieser Funktionen hingen an einem Stück Logik, das noch niemand geprüft hatte, und dieses Stück stand für Monat fünf im Plan. Funktionierte es nicht, war alles davor Ausschuss.

Genau um dieses Reihenfolgeproblem geht es bei der Entwicklung eines KI-MVP im SaaS. Es geht nicht darum, wie schnell Sie Code schreiben. Es geht darum, welchen Code Sie zuerst schreiben und was Sie in der Woche danach lernen.

Die meisten Teams machen es andersherum. Sie bauen das ganze Produkt und zeigen es dann jemandem. Wenn echte Nutzer kommen, liegt das meiste Gebaute unbenutzt herum. Und das eine, was hätte anders sein müssen, wurde in Woche eins entschieden, begraben unter allem, was sich darauf gestapelt hat.

Unser Argument ist schlicht. Wählen Sie die eine Funktion, an der Ihr Geschäftsmodell steht oder fällt. Bauen Sie diese Funktion sauber, auf einer Infrastruktur, die Sie gern behalten wollen, und legen Sie sie einer geschlossenen Gruppe echter Nutzer vor, bevor Sie sonst irgendetwas bauen.

Der teure Weg, zu merken, dass die Roadmap falsch war

Drei Muster tauchen immer wieder auf, und alle drei kosten Monate.

Das erste ist die Roadmap, die vor dem Testen geschrieben wird. Funktionen werden in einem Planungsdokument festgezurrt, der Bau folgt dem Dokument, und nichts darin wird bis zum Start hinterfragt. Dann kommen die Nutzungsdaten. Ein großer Teil des Funktionsumfangs entpuppt sich im ersten Jahr als totes Gewicht. Nicht kaputt. Nur nie geöffnet.

Das zweite ist die Überraschung bei der Einreichung. Ein Team wird fertig, reicht bei einem App-Store ein oder übergibt das Produkt an eine Prüfung der Regelkonformität und stellt fest, dass die Art, wie es Nutzerdaten erhebt, speichert und weiterleitet, nicht trägt. Der Umgang mit Daten ist kein Bildschirm, den man am Ende ergänzt. Er ist eine Entscheidung über das Schema, getroffen in Woche eins, und sie wieder aufzutrennen heißt, alles anzufassen.

Das dritte ist der Prototyp, auf dem man nicht weiterbauen kann. Etwas wird schnell zusammengesteckt, um es Investoren zu zeigen. Es läuft, und dann versucht das Team, die zweite Funktion zu ergänzen. Die Abkürzungen beim Datenmodell oder bei den Rechten erweisen sich als tragend. Der Neubau kostet mehr als der erste Bau.

Dasselbe sehen wir auch von innen. Entwickelnde bauen gern. Bei einem lockeren Auftrag liefern sie mehr, als jemand verlangt hat. Danach verbringt das Team einen Sprint damit, Funktionen wieder herauszunehmen, um das eigentliche Produkt darunter zu finden. Disziplin beim Umfang ist keine Charaktereigenschaft. Sie muss im Plan stehen.

Der dünne Schnitt: eine Funktion, sauber gebaut

Ein MVP ist keine halbfertige Fassung des vollen Produkts. Ein halbfertiges Produkt macht zehn Dinge schlecht und beweist nichts. Der dünne Schnitt macht eine Sache richtig, auf echter Infrastruktur, vor echten Menschen.

Der Schnitt existiert, um eine Frage zu beantworten: Funktioniert die Kernidee, wenn sie jemand benutzt, der nicht Sie ist? Alles andere wird aufgeschrieben und geparkt. Das Aufschreiben zählt. Geparkte Funktionen sind nicht gestrichen, sie sind einsortiert, und diese Sortierung ändert sich, sobald Sie Belege haben.

Sechs Dinge machen die Entscheidung aus, und sie gehören auf eine Seite:

• Die Funktionsliste. Alles, was Sie irgendwann haben wollen, ungefiltert.
• Das Budget. Was Sie tatsächlich ausgeben können, bevor Sie mehr Geld oder Umsatz brauchen.
• Der dünne Schnitt. Die eine Funktion, die zuerst erscheint, gewählt, weil das Geschäftsmodell an ihr hängt.
• Die Roadmap. Was wartet, in welcher Reihenfolge, mit dem Grund daneben.
• Die geschlossene Beta. Eine kleine Gruppe echter Nutzer mit echter Arbeit, keine Freunde, die herumklicken.
• Die Antwort. Was sie damit gemacht haben und was Ihnen das über das Nächste sagt.

Dieser Rahmen hält nur, wenn Sie ihn gegen wuchernden Umfang verteidigen. Gründer, die die Prinzipien eines MVP flüssig erklären können, ergänzen während des Baus trotzdem drei Dinge, weil sich jedes davon im Moment notwendig anfühlt. Die Verteidigung sind Budget und Kalender, beide vor Arbeitsbeginn festgelegt. Schlägt jemand eine Ergänzung vor, lautet die Frage nicht, ob sie eine gute Idee ist. Sie lautet, was dafür herausfliegt.

Wie Sie wählen, was zuerst erscheint

Woche eins ist eine Woche zum Nachdenken, und das Nachdenken ist eng geführt. Woran steht und fällt dieses Produkt?

Ein Diagnosewerkzeug für die Hochschulbildung steht an seiner Diagnosestrecke: Anmeldung der Studierenden, die Tests, die bewertete Auswertung und ein Mensch mit Fachwissen, der das Ergebnis prüft, bevor es zurückgeht. Liefert die Testlogik keine Ergebnisse, unter die jemand aus der Wissenschaft den eigenen Namen setzt, rettet kein Dashboard die Sache. Also warten die Dashboards.

Ein Marketing-Assistent für Handwerks- und Haushaltsdienste steht an seiner Prüfmaschine. Er muss sich die Website eines Installateurs ansehen, finden, was fehlt, und Suchbegriffe vorschlagen, mit denen jemand ohne Marketingausbildung etwas anfangen kann. Das ist das Produkt. Ranking-Verfolgung und Zuordnung von Anfragen sind für Kunden, die schon zahlen, und Sie haben noch keine.

Ein Finanzprodukt steht an seiner Rechenschicht. Die Zahlen müssen stimmen, bevor sich irgendetwas anderes zu bauen lohnt, und der Nachweis dafür besteht darin, echte Fälle hindurchzuschicken, während ein Mensch jedes Ergebnis prüft. Berichtsbildschirme und Exporte für die Aufsicht kommen, wenn die Rechnung hält.

Die Regel unter allen dreien: Liefern Sie den Schnitt aus, der das Geschäftsmodell belegt, und nicht den, der das Produkt vollständig wirken lässt. Vollständigkeit ist ein Gefühl. Was Sie kaufen, sind Belege.

Das ist auch der Punkt, an dem wir manchmal sagen: Bauen Sie es nicht. Lässt sich die Kernfrage mit einer Tabelle, einem gemeinsamen Postfach und einer Woche Handarbeit beantworten, dann machen Sie das. Manche Ideen brauchen Software, um geprüft zu werden. Viele nicht, und das herauszufinden kostet ein Gespräch statt eines Quartals.

Was in Version eins nicht hineingehört

Die Ausschlüsse sind der Ort, an dem das Budget wirklich entsteht. Fünf davon kommen in fast jedem schlanken Plan für ein KI-Produkt vor, den wir schreiben.

Eigene Modelle. Ein eigenes Modell zu trainieren ist ein Forschungsprojekt mit unbekanntem Enddatum. Kommerzielle APIs tragen die erste Fassung, und zwar jetzt. Rechtfertigen Ihre Daten oder Ihre Margen später ein privates LLM-Feintuning mit sicherem Hosting, treffen Sie diese Entscheidung mit Nutzungsdaten in der Hand und nicht aus dem Bauch. Es zu Beginn wegzulassen spart acht bis zwölf Wochen.

Native Mobil-Apps. Zuerst das Web, responsiv. Zwei native Builds plus Einreichung in den Stores bringen Kosten und Prüfrisiko mit, und Testenden in einer geschlossenen Beta genügt der Browser völlig.

Fortgeschrittene Funktionen. Empfehlungsmaschinen, Ranking-Verfolgung, Bewertung nach Verhalten. Alle vernünftig. Keine davon belegt den Kern.

Anbindungen, die den Schnitt nicht tragen. Ein Konnektor mag unverzichtbar sein, weil das Produkt ohne ihn nicht läuft. Die anderen sechs sind Version zwei. Konnektoren zu Fremdsystemen altern schlecht, solange das Produkt drumherum noch seine Form sucht.

Ausgefeilte Dashboards. Bauen Sie gerade so viel Oberfläche, dass jemand die Sache testen kann, ohne dass Sie danebensitzen. Echter Feinschliff wartet, bis Nutzer Ihnen gesagt haben, welche Zahlen sie wirklich ansehen, und das ist selten die Auswahl, die Sie erwartet hätten.

Es gibt die lebhafte These, das klassische MVP sei überholt und Gründer sollten mit Low-Code-Werkzeugen etwas ausliefern, das einem fertigen Produkt näherkommt. Da ist etwas dran. Low-Code bringt Sie schnell in den Markt, wenn das Produkt ein Arbeitsablauf ist. Es hilft nicht mehr, wenn das Produkt die KI-Logik selbst ist, denn dort sitzt die Maßarbeit und dort stößt ein allgemeiner Baukasten an seine Decke.

Drei Architekturentscheidungen, die Sie nicht einsperren

Alle drei fallen in Woche eins, wenn sie nichts extra kosten. Jede davon später zu reparieren, mit Nutzern im System, kostet einen Neubau.

Eine eigene API-Schicht, nicht die eines Anbieters. Jeder Modellaufruf läuft durch eine Schicht, die Sie kontrollieren. Die Anwendung spricht mit Ihrem Backend, Ihr Backend spricht mit dem Anbieter, den Sie gerade nutzen. Wenn ein Anbieter die Preise anhebt, ein Modell abkündigt oder qualitativ überholt wird, ändern Sie einen Dienst. Wir haben erlebt, wie ein Marketingprodukt mitten im Bau wegen eines Kostensprungs den Anbieter wechselte, ohne den Anwendungscode anzufassen. Genau das bringt Ihnen eine maßgeschneiderte KI-API-Integration mit eigener Zwischenschicht.

Datenmodell und Sicherheit vor den Bildschirmen. Mandantentrennung im Schema entworfen statt außen angeschraubt. Modell-Endpunkte so eingestellt, dass der Anbieter nicht mit Kundeneingaben trainiert, mit angeforderter Null-Speicherung überall dort, wo der Anbieter sie anbietet. Rechteregeln geklärt, bevor jemand eine Anmeldeseite baut. Bei regulierter Arbeit gehören Entscheidungen zur sicheren und regelkonformen KI-Architektur in dieselbe Woche wie das Schema.

Produktionsinfrastruktur vom ersten Tag an, nur kleiner. Das MVP läuft auf demselben Hosting wie später das volle Produkt, nur in kleinerer Ausführung. Gleiche Architektur, weniger Ressourcen. Sie wachsen hinein statt heraus, und hinter Ihren ersten hundert Nutzern wartet kein Migrationsprojekt.

In dieser Phase legen wir außerdem eine Verhaltensregel fest. Alles, was Geld berührt oder bei einem Kunden ankommt, bekommt eine menschliche Freigabe. Das Modell entwirft, ein Mensch bestätigt, dann passiert die Handlung. Das gilt im MVP und es gilt danach.

Was die Wochen tatsächlich kosten

Woche 1 und 2. Architektur und Sicherheitsaufnahme. In dieser Phase arbeiten ein bis zwei Entwickelnde. Die Datenstrecke wird gezeichnet, bevor eine Zeile Code existiert. Die Mandantenstruktur wird entschieden. Modell-Endpunkte werden gewählt und die Einstellungen zur Speicherung bestätigt. Geliefert wird ein kalkulierter Plan, der den Schnitt benennt, das Ausgeschlossene benennt und Team und Zeitrahmen für den Bau nennt.

Am Ende dieser zwei Wochen sollten Sie mit einem Dokument weggehen können, das Ihnen auch dann nützt, wenn Sie jemand anderen beauftragen.

Ab Woche 3. Den Schnitt bauen. Kernlogik und Backend zuerst, denn dort sitzt das Risiko. Die KI-Anbindung kommt obendrauf, dann gerade so viel Oberfläche, dass jemand aus der geschlossenen Beta ohne Hilfe zurechtkommt. Kein Feinschliff.

Woher die Ersparnis kommt, unverblümt:

• API zuerst statt eines eigenen Modells: acht bis zwölf Wochen weniger im Kalender.
• Eine Funktion sauber gebaut statt zehn halb: meist fallen 40 bis 50 Prozent des Umfangs weg.
• Datenumgang vorab geklärt: keine Neufassung, wenn jemand fragt, wie Datensätze gespeichert werden.
• Geschlossene Beta vor dem öffentlichen Start: die ernsten Probleme zeigen sich vor zwanzig Menschen, nicht vor zweitausend.

Ein dünner Schnitt landet üblicherweise zwischen 40.000 und 100.000 $, je nachdem, wie viel Logik dahintersteckt. Das ist eine weite Spanne, und der ehrliche Grund dafür ist, dass eine Strecke zur Dokumentenanalyse und eine Maschine für Finanzberechnungen nicht denselben Aufwand bedeuten. Wir nennen Teamgröße und Dauer vor dem Start, die Zahl steht also fest, bevor Sie sich binden. Code, Konten und Schlüssel gehören durchgehend Ihnen, die Zahl, der Sie zustimmen, ist damit die ganze Zahl.

Gründerinnen und Gründer ohne technischen Hintergrund verbringen oft sechs Monate und viel Geld mit einem Entwicklungspartner, bevor sie merken, dass ein kleinerer erster Schritt möglich gewesen wäre. Ein funktionierender Schnitt vor Testenden innerhalb des ersten Quartals ist heute eine vernünftige Erwartung, und das ist der Maßstab, nach dem wir bauen.

Was zuerst erschien: drei Beispiele

Eine Diagnoseplattform für die Hochschulbildung im Vereinigten Königreich. Erschienen: Registrierung, sechs akademische Tests, KI-bewertete Auswertung und fachliche Prüfung, bevor Ergebnisse herausgingen. Gewartet: Dashboards, die Personalisierung, Inhaltsbibliotheken, Berichte für Hochschulen. Die Methodik war das Produkt. Solange die Bewertung der akademischen Prüfung nicht standhielt, hatte nichts darüber einen Wert.

Ein Marketing-Assistent für Betriebe im Haushaltsservice. Erschienen: Website-Prüfung, Analyse der Suchbegriffe, Texterstellung und ein schlichtes Dashboard. Gewartet: Ranking-Verfolgung, CRM-Anbindung, Zuordnung von Anfragen, Nachfassen per SMS. Prüfung und Suchbegriffe belegen, dass das Werkzeug das Problem löst, das ein Betrieb tatsächlich hat. Zuordnung zählt, sobald es Umsatz zuzuordnen gibt.

Ein Werkzeug zur Prüfungsvorbereitung für Nachhilfekräfte. Erschienen: Dokumentenanalyse, Auslesen der Bewertungsraster und priorisierte Hinweise zur Vorbereitung. Gewartet: Videokonferenz, ein vollständiger Marktplatz, automatische Moderation. Die Analyse und die Rückmeldeschleife sind das, wofür Menschen zahlen. Alles andere war Infrastruktur um ein Produkt herum, das noch niemand bestätigt hatte.

In allen drei Fällen kamen die ersten Kunden daher, dass die Gründer selbst verkauft haben, nicht aus einer Startkampagne oder bezahlter Werbung. Der Gründer sprach mit Menschen, die das Problem haben, sah ihnen beim Benutzen des Schnitts zu und passte an. Dieser Kanal wirkt in dieser Phase besser als alles andere, und er ist der schnellste Weg zu erfahren, was in Version zwei gehört. Schnelles KI-Prototyping gibt es dafür, Ihnen etwas Echtes für diese Gespräche in die Hand zu geben.

Was schiefgeht, wenn Sie den Schnitt überspringen

Wuchernder Umfang richtet mehr Schaden an als Fehler. Fehler werden gefunden und behoben. Wuchernder Umfang schiebt den Start um Monate, während das Team Funktionen baut, die ein echter Nutzer Ihnen ausgeredet hätte, und Sie erfahren es erst, nachdem Sie dafür bezahlt haben.

Überraschungen beim Datenumgang kommen spät und kommen hart. App-Stores und Aufsichtsbehörden schauen auf Erhebung, Speicherung und Übermittlung. Das am Ende zu entwerfen heißt, Entscheidungen aus Woche eins aufzutrennen. Finanzen und Gesundheit verzeihen am wenigsten, und eine Zulassung kann Ihnen niemand garantieren. In Ihrer Hand liegt, ob Ihre Architektur die Fragen übersteht.

Die Bindung an einen Anbieter wächst leise. Das SDK eines Anbieters quer durch Ihren Code heißt, ein Wechsel kostet einen Neubau. Speichereinstellungen, die Sie nie geändert haben, heißen, dass Kundeneingaben womöglich auf fremder Infrastruktur liegen. Hosting, das Sie nicht kontrollieren, heißt, Sie können weder umziehen noch neu verhandeln, wenn es nötig wird.

Der Prototyp, auf dem niemand weiterbauen kann, bleibt der teuerste der vier Fehlschläge, weil er bis zur zweiten Funktion wie ein Erfolg aussieht.

Fragen, bevor jemand Code schreibt

Sechs Fragen. Wenn Sie die beantworten können, ist Ihr schlanker Plan für ein KI-Produkt zum größten Teil geschrieben.

• Welche einzelne Funktion belegt die Idee oder erledigt sie?
• Können Sie das mit einer API belegen statt mit einem selbst trainierten Modell?
• Welche Datenregeln müssen am ersten Tag stimmen und nicht am neunzigsten?
• Wer nutzt Version eins, mit Namen, und was will diese Person erreichen?
• Welche Anbindungen können ehrlich warten, bis Geld hereinkommt?
• Wem gehören Code, Cloud-Konten und API-Schlüssel, wenn der Bau endet?

Die letzte wird öfter übersprungen, als sie sollte. Lautet die Antwort nicht „Ihnen“, zählt der Rest des Plans wenig.

Wann Sie aufhören zu planen und anfangen zu bauen

Sie werden vor dem Start nicht alle Antworten haben. Genau darum geht es, einen Schnitt zu bauen statt ein Produkt. Zwanzig echte Nutzer mit echter Arbeit sagen Ihnen in zwei Wochen mehr als ein weiterer Monat Planungsrunden, und sie sagen Ihnen Dinge, nach denen Sie nie gefragt hätten.

Die Werkzeuge ändern sich laufend, und KI-Assistenten beim Programmieren haben die Bauphase wirklich beschleunigt. Das stimmt. Nicht geändert hat sich der Teil, der entscheidet, ob das Geld gut angelegt war: die richtige erste Funktion zu wählen und sie auf einem Fundament zu bauen, das Sie behalten können. Das ist die ganze Disziplin hinter der Entwicklung eines KI-MVP, und sie ist älter als jedes der heutigen Werkzeuge.

Wenn Sie Hilfe dabei wollen, Ihren Schnitt zu finden, buchen Sie ein kostenloses Automatisierungs-Audit. Wir bestimmen die eine Funktion, die Ihre Idee belegt, kalkulieren den Plan und sagen Ihnen offen, wenn Sie besser nicht bauen sollten. Sie können sich auch ansehen, wie unsere maßgeschneiderten KI-MVP zugeschnitten und bepreist werden, oder lesen, wie wir mit Kunden arbeiten, bevor Sie sich melden.

Arun Andiselvam

LinkedIn

Ich bin Gründer und habe fünf Marken aufgebaut. Die erste, ein SEO-Werkzeug, habe ich für einen sechsstelligen Betrag verkauft, und heute entwickle ich KI-Automatisierung für Unternehmen. Jede davon habe ich vom ersten Tag an aus eigener Kraft finanziert.