Wie man ein MVP ohne Entwickler baut, und was niemand vorher sagt

Das Bauen hat aufgehört, der Engpass zu sein. Fast niemand hat seinen Plan darauf angepasst.

Hier ist die Frage, die mir gestellt wird, und die Frage darunter.

Die gestellte Frage: kann ich mein Produkt bauen, ohne jemanden für die Entwicklung einzustellen? Ja. 2026 kann eine Person allein mit KI-Werkzeugen in etwa einer Woche eine funktionierende Anwendung online haben, gegenüber einem klassischen MVP-Zeitplan von acht bis sechzehn Wochen. Die Daten von Altar.io setzen den Durchschnitt näher an vier Monate, wobei drei Monate der häufigste Wert sind.

Die Frage darunter: wird das funktionieren? Und die ehrliche Antwort ist, dass es von Dingen abhängt, die nichts mit dem Bauen zu tun haben.

CB Insights analysierte 431 gescheiterte, mit Wagniskapital finanzierte Unternehmen und fand, dass 43 Prozent an mangelnder Passung zwischen Produkt und Markt scheiterten. 70 Prozent „ging das Kapital aus”, was dieselbe Analyse als Symptom und nicht als Ursache behandelt. Kein Geld mehr zu haben ist, was auf dem Weg zum eigentlichen Problem passiert.

Keines dieser Scheitern wurde durch langsame Entwicklung verursacht. Das heißt, den Engpass der Entwicklung zu entfernen bewegt die Zahl für sich allein nicht.

Was sich genau geändert hat

Nicht „Software ist jetzt einfach”. Etwas Engeres und Nützlicheres.

Die Kosten für die Erzeugung einer Anwendung sind eingestürzt. Die Kosten der Entscheidung, was die Anwendung sein soll, haben sich überhaupt nicht bewegt.

Zwanzig Jahre lang verbarg der Engpass der Entwicklung diese zweiten Kosten. Als das Bauen vier Monate und 80.000 Dollar dauerte, erzwangen die vier Monate eine Art Disziplin: Sie hatten Zeit, mit Kunden zu sprechen, während die Entwicklung arbeitete, und die Ausgabe brachte Sie dazu, vor der Zusage nachzudenken.

Nehmen Sie die vier Monate weg, und das Nachdenken ist jetzt optional. Das ist das eigentliche Risiko 2026, und es ist ein neues. Sie können das Falsche viel schneller bauen als früher, und es wird beeindruckend fertig aussehen, während es falsch ist.

Die vier Entscheidungen, bevor Sie irgendetwas prompten

Kein Prozess. Vier Fragen, und Sie können alle an einem Nachmittag beantworten.

1. Für wen genau ist das, und was tun diese Menschen heute stattdessen?

Kein Markt. Eine Person und ihr aktueller Behelf: eine Tabelle, eine WhatsApp-Gruppe, eine Agentur, drei Stunden am Sonntag. Wenn Sie den Behelf nicht benennen können, wissen Sie noch nicht, ob das Problem echt ist, denn alle haben einen Behelf für Probleme, die tatsächlich schmerzen.

2. Was ist die eine Sache, die es tun muss?

Die einzelne Handlung, die den Tag von jemandem besser macht. Alles andere ist Version zwei. Das zählt heute mehr als früher, weil KI-Werkzeuge bereitwillig alle neun Funktionen bauen, die Sie beschreiben, und neun Funktionen sind der Weg zu einem Produkt, das niemand erklären kann.

3. Welche Dinge gibt es in Ihrem Produkt, und wie hängen sie zusammen?

Das ist die Frage, die Gründer überspringen, und diejenige, die entscheidet, ob der sechste Monat überlebbar ist. Nutzer, Bestellungen, Projekte, Rechnungen, was auch immer Ihre Substantive sind. Was zu was gehört. Was eindeutig sein muss. Was passiert, wenn eines gelöscht wird.

Sie brauchen kein technisches Vokabular. „Ein Kunde kann viele Projekte haben, ein Projekt hat genau einen Eigentümer, zwei Kunden können sich keine E-Mail-Adresse teilen” ist ein Datenmodell. Das aufzuschreiben dauert fünfzehn Minuten und ist die wirkungsvollste Viertelstunde des ganzen Vorhabens. Wenn das Vokabular unbekannt ist, behandelt das technische Glossar die Begriffe, ohne vorauszusetzen, dass Sie sie schon kennen.

4. Woran werden Sie erkennen, ob es funktioniert?

Wählen Sie die Zahl vor dem Start, denn nach dem Start werden Sie eine Zahl finden, die ermutigend aussieht. Anmeldungen sind meist die falsche. Ob überhaupt jemand ein zweites Mal zurückkam, ist meist die richtige.

Warum die dritte Frage diejenige ist, die zubeißt

Wegen dem, was passiert, wenn Sie sie überspringen.

Jede Entscheidung, die Sie nicht ausdrücklich treffen, wird trotzdem getroffen. Sie wird vom Generator getroffen, zum Zeitpunkt der Generierung, aus einem Kontext, der Ihr Geschäft nicht enthält. Das Werkzeug hält nicht an und fragt, ob zwei Kunden sich eine E-Mail-Adresse teilen können. Es wählt etwas Plausibles und macht weiter.

Dann brauchen Sie im vierten Monat Teams, oder Abrechnung, oder einen zweiten Nutzertyp, und es stellt sich heraus, dass die in Woche eins stillschweigend gewählte Antwort diese Änderung zu einem Neubau statt zu einer Ergänzung macht. Jede Korrektur zerbricht etwas anderes. Mehr Prompten macht es schlimmer.

Entwickler nennen das das 70-Prozent-Problem: die App erreicht den Zustand fast fertig und kommt nicht weiter. Der Blocker ist nie fehlender Code. Es ist eine Entscheidung, die Hunderte Generierungen früher implizit getroffen wurde und nicht mehr günstig geändert werden kann.

Die Fassung davon auf Branchenebene ist messbar. DORAs Untersuchung von 2025 fand, dass eine höhere KI-Nutzung mit steigendem Liefer-Durchsatz und steigender Instabilität einhergeht, gleichzeitig: schneller und zerbrechlicher zusammen. GitClears Analyse von 623 Millionen Codeänderungen fand duplizierten Code um 81 Prozent gegenüber der Basislinie von 2023 gestiegen, während die Refactoring-Aktivität von 21 Prozent der Änderungen im Jahr 2022 auf 3,8 Prozent im Jahr 2026 fiel.

Generierung ist günstig. Kohärenz nicht, und nichts erzeugt sie zufällig. Die Praxis, die dagegen gebaut wurde, ist spezifikationsgetriebene Entwicklung, und die architektonische Fassung des Arguments steht hier.

Was tatsächlich zu tun ist, in dieser Reihenfolge

1. Schreiben Sie die vier Antworten auf. Eine Seite. Tun Sie das, bevor Sie irgendein Werkzeug öffnen. Wenn Sie Frage drei nicht beantworten können, sind Sie nicht bereit zu bauen, sondern bereit, mit zwei weiteren Kunden zu sprechen.
2. Wählen Sie ein Werkzeug danach, was im sechsten Monat passiert, nicht danach, was heute Nachmittag passiert. Jede Option dieser Kategorie erzeugt heute etwas Beeindruckendes. Sie unterscheiden sich enorm darin, ob Sie es später noch erweitern können. Die Landschaft, ehrlich verglichen.
3. Bauen Sie die eine Sache. Widerstehen Sie der zweiten Funktion, bis jemand die erste zweimal genutzt hat. Das ist viel schwerer, als es klingt, wenn das Hinzufügen von Funktionen fast gratis ist.
4. Zeigen Sie es fünf echten Menschen, nicht fünfzig. Fünf Menschen, die das Problem haben, sagen Ihnen mehr als fünfzig, die höflich sind. Beobachten Sie, wo sie aufhören, statt zu fragen, ob es ihnen gefiel.
5. Entscheiden Sie, was Sie mit der Zahl machen. Wenn niemand zurückkam, lautet die Antwort nicht mehr Funktionen. Sie lautet Frage eins, noch einmal.

Wofür Sie wirklich noch jemanden aus der Entwicklung brauchen

Ich sage das lieber offen, als Ihnen eine Phantasie zu verkaufen.

Alles, wo Irren teuer ist. Zahlungen jenseits einer üblichen Kasse, Gesundheitsdaten, alles Regulierte. Nicht weil die Werkzeuge es nicht erzeugen könnten, sondern weil Sie nicht bewerten können, ob das Erzeugte sicher ist, und in diesen Feldern ist „sah gut aus” kein Standard.

Migrationen unter Last. Die Form lebender Daten mit echten Kunden darauf zu ändern ist wirklich schwer und geht leise schief.

Der Moment, in dem es funktioniert. Das ist das gute Problem. Wenn die Nutzung wächst, muss jemand, der das System versteht, es übernehmen. Planen Sie diese Einstellung als Erfolgsmeilenstein und nicht als etwas, das Sie hätten vermeiden sollen.

Wofür Sie wahrscheinlich niemanden aus der Entwicklung brauchen: um an den Punkt zu kommen, an dem Sie wissen, ob überhaupt jemand das will. Früher brauchte das eine Person. Heute nicht mehr, und das ist eine echte Veränderung, die es lohnt zu nutzen.

Die Falle der beeindruckenden Demo

Ein funktionierender Bildschirm ist enorm überzeugend, auch für Sie selbst.

Sie werden ihn Menschen zeigen, und sie werden ermutigend sein, denn eine ausgefeilte Oberfläche anzuschauen erzeugt eine andere Reaktion als die Aufforderung, die eigene Arbeitsweise zu ändern. Ermutigung ist kein Beweis. Die Demo ist nur etwas wert, wenn jemand sie zweimal nutzt, ohne dass Sie im Raum sind.

Ich sähe lieber eine Gründerin mit einem hässlichen Produkt und vierzig wiederkehrenden Nutzern als eine mit einem schönen Produkt, vierhundert Anmeldungen und keinen zweiten Besuchen. Das Zweite ist viel leichter zu bekommen und viel schwerer zu heilen, weil es sich wie Fortschritt anfühlt.

Der Teil, der nicht leichter wurde

Sie können die Sache heute in einer Woche bauen. Das ist real, es ist wirklich neu, und wer Ihnen etwas anderes sagt, hat es zuletzt nicht versucht.

Aber 43 Prozent jener 431 gescheiterten Unternehmen starben an mangelnder Passung zwischen Produkt und Markt, und nicht eines starb, weil das Bauen zu lange dauerte. Der Engpass hat sich verschoben. Er verschob sich zu dem Teil, der immer der schwere war und früher hinter vier Monaten Entwicklung verborgen lag.

Welche Entscheidungen, in welcher Reihenfolge, für wen. Das ist jetzt die Arbeit. Es war immer die Arbeit.

Das Bauen war nur laut genug, um sie zu übertönen.

Weiterführende Lektüre

Speziell zu den architektonischen Entscheidungen: SaaS-Entwicklung für Gründer ohne technisches Profil. Dazu, was die Werkzeuge Sie tatsächlich kosten: Token, Credits oder Aufwand.

Häufig gestellte Fragen

Kann man 2026 wirklich eine App ohne Entwickler bauen? Ja. Eine Person ohne technisches Profil kann mit KI-App-Buildern in etwa einer Woche eine funktionierende Anwendung online bringen, gegenüber einem klassischen MVP-Zeitplan von acht bis sechzehn Wochen. Die Beschränkung ist nicht länger, ob Sie es bauen können, sondern ob Sie vor dem Start die richtigen Dinge entschieden haben.

Wie lange dauert es, ein MVP zu bauen? Klassisch acht bis sechzehn Wochen, wobei Daten den Durchschnitt näher an vier Monate setzen und drei Monate der häufigste Zeitplan sind. Mit KI-Werkzeugen kann eine Person allein in etwa einer Woche ein funktionierendes Produkt erreichen, wobei diese Geschwindigkeit nur hilft, wenn die darunterliegenden Entscheidungen bewusst getroffen wurden.

Was sollte ich vor dem Bauen entscheiden? Vier Dinge: für wen es ist und was diese Menschen heute stattdessen tun, die einzelne Handlung, die das Produkt unterstützen muss, welche Dinge es in Ihrem Produkt gibt und wie sie zusammenhängen, und die Zahl, die Ihnen sagt, ob es funktioniert. Das Dritte überspringen die meisten Gründer, und es verursacht später die teuersten Probleme.

Warum hören KI-gebaute MVPs nach einigen Monaten auf zu funktionieren? Weil Entscheidungen, die niemand ausdrücklich traf, implizit vom Generator getroffen wurden, und diese Entscheidungen alles danach begrenzen. Das ist das 70-Prozent-Problem: die App erreicht den Zustand fast fertig und stockt, weil der Blocker eine architektonische Wahl ist und keine fehlende Funktionalität.

Muss ich Datenbanken verstehen, um ein MVP zu bauen? Sie brauchen kein technisches Vokabular, aber Sie müssen sagen können, welche Dinge in Ihrem Produkt existieren und wie sie zusammenhängen. „Ein Kunde kann viele Projekte haben, ein Projekt hat einen Eigentümer, zwei Kunden können sich keine E-Mail-Adresse teilen” ist ein Datenmodell in einfacher Sprache, und das aufzuschreiben ist eines der wertvollsten Dinge, die Sie tun können.

Wann muss ich tatsächlich jemanden für die Entwicklung einstellen? Für alles, wo Irren teuer ist (regulierte Daten, Zahlungen jenseits der üblichen Kasse), weil Sie nicht bewerten können, ob das Ergebnis sicher ist. Für die Migration lebender Daten unter Last. Und wenn das Produkt zu funktionieren beginnt und jemand das System richtig übernehmen muss. Behandeln Sie den letzten Punkt als Erfolgsmeilenstein.

Was kostet es, ein MVP ohne Entwickler zu bauen? Die Werkzeuge reichen von kostenlosen Stufen bis zu einigen hundert Dollar im Monat, je nachdem, wie viel Sie iterieren, und das ist dramatisch weniger als ein klassischer Bau. Die Kosten, die Gründer überraschen, sind die nach dem Start: Hosting, wenn die Nutzung wächst, und der Neubau, wenn die frühe Architektur die nächste Funktion nicht tragen kann.