Von der Idee zum Umsatz: Das kleinste tragfähige Produkt, das du mit KI bauen kannst

Du brauchst kein "richtiges" MVP mehr. Hier ist, wie das kleinste tragfähige Produkt 2026 wirklich aussieht — und wie du es dieses Wochenende launchst.

Der alte Weg funktioniert nicht mehr

Vor fünf Jahren war das Startup-Playbook: Idee aussuchen, drei Monate am MVP bauen, ins Leere launchen, iterieren.

Damals hieß “MVP” so viel wie “alle Basis-Features, super poliert, bereit für eine Warteliste”.

Mit KI-App-Buildern wie Proyecta sieht der Zeitplan anders aus. Du kannst etwas Echtes haben — keine Landingpage, kein Mockup, sondern ein tatsächlich funktionierendes Produkt — bis morgen Mittag. Aber fast niemand weiß, wie man darüber nachdenken soll, was “am kleinsten” eigentlich bedeutet, wenn man mit KI baut.

Hier ist, was ich beobachte: Die meisten launchen viel zu viel. Sie bauen ein Dashboard ein, Nutzerkonten, Integrationen, Analytics, vielleicht eine Mobile-App-Version. Dann nutzt es niemand, weil sie auf Vollständigkeit optimiert haben — Häkchen setzen — statt darauf, ein konkretes Problem für eine konkrete Person zu lösen, und zwar jetzt.

Was “am kleinsten” heute wirklich heißt

Das kleinste tragfähige Produkt mit KI ist so klein, dass es fast komisch ist. Es ist:

Ein Workflow. Nicht fünf Features. Eine Sache, die deine Zielperson immer wieder macht und die heute 10 Minuten dauert, und deine App kürzt sie auf 30 Sekunden.

Keine Konten. Wenn du es ohne Login ausliefern kannst — mach das. Eine Person, eine Sitzung, ein Ergebnis. Wenn es gefällt, kannst du Konten später hinzufügen. Stripe-Login-Abläufe richtig zu bauen dauert 20 Minuten. Einmalige Sitzungen dauern fünf.

Keine Datenbank. Zumindest keine, die du selbst verwaltest. Pack deine Daten in ein Google Sheet. Nutz localStorage im Browser. Nutz Stripe oder Airtable als dein Backend. Du willst Kund:innen finden, keine Infrastruktur bauen.

Eine Integration. Such dir das eine Tool aus, das deine Kund:innen ohnehin schon nutzen, und integrier dich damit. “Funktioniert mit Slack” oder “liest aus deinem Google Drive” ist viel nützlicher als “hat ein eigenes Ablagesystem”.

Hier ein konkretes Beispiel: Sarah hat ein Tool für freiberufliche Designer:innen gebaut, die ewig damit verbringen, neuen Kund:innen ihren Stil zu erklären. Ihre App: Du lädst drei deiner besten Designs hoch, beschreibst deinen Prozess in einfacher Sprache, und die App generiert ein “Style Guide”-PDF, das der oder die Designer:in an Kund:innen schicken kann. Das war’s. Keine Konten, kein Login, kein Dashboard. Jedes Mal, wenn jemand es nutzt, fängt er bei null an. Die App läuft in Proyecta, sie nutzt Stripe für Zahlungen (es generiert pro PDF einen einmaligen Link), und wenn Leute nach mehr Features fragen (etwa “mehrere Stile speichern”), baut sie es vielleicht ein — oder merkt, dass ihr eigentliches Produkt nicht die App ist, sondern der Verkauf dieser PDFs als Vorlagen.

Sie hat in der ersten Woche 600 Dollar gemacht.

Die drei Kennzahlen, auf die es wirklich ankommt

Miss nicht Vollständigkeit. Miss nicht die Verweildauer. Miss diese drei:

  1. Zeit bis zum ersten Nutzen. Von “Ich habe diesen Link gefunden” bis “Ich habe ein Ergebnis, das ich tatsächlich nutzen kann”. Bei Sarahs Tool: 90 Sekunden. Wenn es länger als fünf Minuten dauert, springen Leute ab.

  2. Zahlungsbereitschaft. Launch nicht mit einem Gratis-Tarif und einem Pro-Tarif. Such einen Preis aus. Sieh, ob Leute ihn zahlen. (25 Dollar für Sarahs PDFs. Sie könnte mehr verlangen; sie verlangt weniger, weil sie nur validieren will.) Wenn die Antwort “auf keinen Fall” lautet, hast du das falsche Problem gewählt.

  3. Kommen-sie-wieder-Rate. Für ein einmaliges Tool brauchst du keine 30-Tage-Retention. Du musst wissen: Von den Leuten, die das einmal genutzt haben, wie viele erzählen es einer Freundin oder einem Freund? Sarahs Retention-Kennzahl ist “hat mindestens einer anderen Person aus dem Design erzählt”. Das sind bisher 40 %.

Wenn alle drei gut sind, hast du etwas. Jetzt kannst du Konten, Dashboards, Verlauf und all das hinzufügen.

Wie du an einem Wochenende launchst

Freitagmorgen: Such dein Problem. Keinen Markt. Keinen Trend. Eine konkrete Person, die eine konkrete Sache macht, die heute nervt.

Freitagnachmittag bis Samstagvormittag: Nutz Proyecta, um es zu bauen. Du beschreibst, was du willst (“nimm einen PDF-Vertrag und markier alle Zahlungsbedingungen rot”), Proyecta generiert es, du testest, justierst, bis es passt. Vier Stunden, vielleicht sechs, wenn du pingelig bist. Du hast jetzt eine funktionierende Web-App.

Samstagnachmittag: Teste es an zwei Personen. Nicht “Hey, würdest du das theoretisch nutzen?”, sondern “hier ist der Link, nutz es wirklich, und sag mir, was kaputt war oder sich komisch anfühlte”.

Sonntagvormittag: Richte Zahlungen ein, wenn du etwas verlangst. Stripe, Gumroad, ein simpler Link — du baust keine Abrechnungsplattform. Nur eine Möglichkeit zu kassieren.

Sonntagabend: Liefer es aus. Post auf Show HN, in relevante Discord- oder Slack-Gruppen, schreib fünf Leuten direkt eine E-Mail. Zerbrich dir nicht den Kopf über die Beschreibung. Fang damit an, warum du es gebaut hast: “Ich habe das gemacht, weil mich frustriert hat, dass …”

Montag: Sieh, was tatsächlich passiert. Echte Menschen nutzen es oder eben nicht. Du weißt es innerhalb von 48 Stunden.

Was als Nächstes passiert (der einfache Teil)

Wenn es niemand nutzt: Du hast schnell und günstig etwas gelernt. Du hast bis Dienstag gepivotet.

Wenn ein paar Leute es nutzen: Du beobachtest, was sie tatsächlich damit machen. Nutzen sie es genau so, wie du es entworfen hast, oder machen sie etwas leicht anderes? Fragen sie nach Features, die du nicht erwartet hast, oder nutzen sie es einfach still und gehen wieder?

Wenn Leute es nutzen, nach Dingen fragen und du dir sicher bist, dass du daran arbeiten willst: Jetzt kannst du in das ordentliche Zeug investieren. Konten, damit Leute ihre Arbeit speichern können. Ein Dashboard, damit sie sehen, was sie gebaut haben. Eine API, wenn sie das brauchen. Aber du baust diese Features, weil du weißt, dass es Nachfrage gibt, nicht weil du glaubst, dass sie existieren sollten.

Der größte Fehler ist, mit der Annahme auszuliefern, dass deine Idee richtig ist und dein einziger Job darin besteht, Leute davon zu überzeugen. Das kleinste tragfähige Produkt ist der erste Test dieser Annahme. Alles danach ist nur Zuhören.

Drei echte Geschichten

Marcus (Datenanalyst): Verbrachte jede Woche eine Stunde damit, SQL-Abfragen für Junior-Analyst:innen manuell neu zu formatieren. Baute ein Tool in Proyecta, das es mit einem Klick erledigt: Abfrage einfügen, formatierte Version bekommen. Ein Eingabefeld, ein Button. Launchte es an einem Dienstag. Bis Freitag hatte er 300 Nutzungen von Leuten aus seinem Discord. Bis Monatsende: 1.200 Nutzungen, manche von völlig Fremden. Er fügte Konten hinzu, damit Leute ihren Verlauf sehen können, und baute dann eine Integration mit seinem Data Warehouse. Es ist inzwischen sein zweites Einkommen.

Jade (Illustratorin): Baute ein Tool, das aus einer Sprachnachricht eine Charakterskizze auf Basis der Beschreibung generiert. Verbrachte 45 Minuten mit dem Bauen. Verlangte 3 Dollar pro Skizze. Machte in den ersten zwei Wochen 1.500 Dollar, bevor sie pausierte, weil sie so viele Bestellungen bekam, dass sie mit der Geschäftsverwaltung nicht hinterherkam.

Omar (Gründer): Wollte eine “komplette Plattform” bauen. Verbrachte zwei Monate. Launchte mit Konten, Preisstufen, Integrationen mit drei Tools und einem Tutorial-Video. Drei Monate später: 12 Nutzer:innen, zwei davon waren seine Freunde. Er erkannte, dass er für den Launch optimiert hatte statt für das Lernen. Sein Neustart ist viel kleiner — nur der Kern-Workflow — und er bekommt echte Zugkraft.

Das, was dir niemand sagt

Klein auszuliefern ist beängstigend, weil es sich unfertig anfühlt. Dein Hirn schreit “aber wir müssen [Sonderfall] behandeln, was ist mit [Feature], sollten wir nicht [Komplexität hinzufügen]?”.

Nein. Liefer es trotzdem aus.

Dein Job ist nicht, das perfekte Produkt zu bauen. Dein Job ist, die kleinste Wette zu testen, die beweist, dass du ein echtes Problem für eine echte Person löst. Alles danach ist nur Zuhören und Iterieren auf Basis dessen, was real ist.


Was könntest du dieses Wochenende mit einem KI-App-Builder bauen? Etwas Winziges. Etwas, das du selbst nutzen würdest. Probier es aus und sieh, was passiert.