No-Code-MVP: Wann es reicht und wann nicht
Kurz gesagt
Ein No-Code-MVP reicht, wenn dein Produkt vor allem aus Formularen, Datenbank, Abläufen und Benachrichtigungen besteht und die ersten hundert Kunden noch keine hohe Last erzeugen. Es reicht nicht bei rechenintensiver Logik, strengen Datenschutzvorgaben ohne passende Verträge oder wenn der Code selbst dein Wettbewerbsvorteil ist.
Viele Gründer überspringen No-Code, weil sie glauben, ein „echtes” Produkt müsse programmiert sein. Das ist teuer gedacht. Für die erste Version geht es nicht um Technik, sondern um die Frage, ob Kunden das Problem gelöst haben wollen und dafür zahlen. Wenn ein Baukasten diese Frage in drei Wochen beantwortet, ist er die bessere Wahl als vier Monate Eigenentwicklung.
Das heißt nicht, dass No-Code immer passt. Die Grenzen sind real, und manche merkt man erst, wenn es teuer wird.
Wofür No-Code gut ist
Ein großer Teil früher Softwareprodukte besteht aus denselben Bausteinen. Jemand trägt Daten in ein Formular ein, die landen in einer Datenbank, lösen eine Aktion aus und erzeugen eine Benachrichtigung. Dazu ein Login und eine Übersicht. Genau dafür sind No-Code-Plattformen gebaut.
Typische Fälle, in denen ein No-Code-MVP gut funktioniert: ein Kundenportal für Dienstleister, ein kleiner Marktplatz mit wenigen hundert Angeboten, ein internes Werkzeug für eine Branche, eine Buchungs- oder Antragsstrecke. In allen Fällen ist der Wert für den Kunden der Ablauf, nicht ein besonderer Algorithmus.
Ein unterschätzter Vorteil ist die Geschwindigkeit bei Änderungen. Wenn nach dem fünften Kundengespräch klar wird, dass ein Feld fehlt oder ein Schritt überflüssig ist, änderst du das am selben Nachmittag. Bei einer Eigenentwicklung wäre das ein Ticket für die nächste Woche.
Wo die Grenzen liegen
Rechenintensive oder sehr individuelle Logik ist der erste Stolperstein. Wer Routen optimiert, große Datenmengen verarbeitet oder eigene Modelle trainiert, stößt schnell an die Grenzen der Baukästen oder an ihre Preisstufen.
Der zweite ist die Last. No-Code-Plattformen rechnen oft nach Verbrauch ab. Bubble etwa zählt sogenannte Workload Units. Im kostenlosen Tarif sind 50.000 pro Monat enthalten, im Starter-Tarif für 59 US-Dollar monatlich bei jährlicher Zahlung 175.000, im Growth-Tarif für 209 US-Dollar 250.000. Wie viele davon dein Produkt verbraucht, weißt du erst im Betrieb.
Der dritte ist die Abhängigkeit vom Anbieter. Laut Bubble-Handbuch laufen Bubble-Apps nur auf der Bubble-Plattform, ein Export als Code ist nicht möglich. Wer wechseln will, muss die Logik neu bauen. Steigen die Preise oder ändert sich das Angebot, kannst du nur zahlen oder neu bauen. Für ein MVP ist das verkraftbar, für ein Unternehmen mit tausend Kunden ein ernstes Risiko.
Was die DSGVO verlangt
Sobald dein MVP personenbezogene Daten verarbeitet, und das tut fast jedes, ist der No-Code-Anbieter dein Auftragsverarbeiter. Du brauchst mit ihm einen Vertrag nach Art. 28 DSGVO. Die meisten großen Anbieter stellen den als Standarddokument bereit, manchmal erst ab einem bestimmten Tarif.
Liegen die Daten bei einem US-Anbieter, kommt die Frage der Übermittlung dazu. Seit Juli 2023 gibt es dafür das EU-US Data Privacy Framework. Ob ein Anbieter zertifiziert ist, lässt sich auf der offiziellen Liste des Data Privacy Framework prüfen. Ist er es nicht, brauchst du andere Garantien wie Standardvertragsklauseln.
Für Produkte im Gesundheitsbereich, mit Sozialdaten oder für Behörden reicht das oft nicht. Dort verlangen Kunden Datenhaltung in Deutschland oder der EU und Nachweise, die viele Baukästen nicht liefern. Prüf das vor dem Bau, nicht nach dem ersten Vertriebsgespräch.
No-Code, Low-Code oder eigener Code?
| Kriterium | No-Code | Low-Code | Eigener Code |
|---|---|---|---|
| Zeit bis zur ersten Version | Tage bis Wochen | Wochen | Monate |
| Programmierkenntnisse nötig | teilweise | ||
| Laufende Lizenzkosten | nein (nur Hosting) | ||
| Komplexe eigene Logik | teilweise | teilweise | |
| Code exportierbar | meist nein | teilweise | |
| Änderungen ohne Entwickler | teilweise |
Grobe Einordnung. Einzelne Plattformen weichen ab, daher vor der Entscheidung die Doku des Anbieters prüfen.
Die Tabelle zeigt den eigentlichen Tausch. No-Code kauft Geschwindigkeit und Unabhängigkeit von Entwicklern gegen laufende Kosten und Abhängigkeit vom Anbieter. Für die Phase, in der du herausfindest, was Kunden wollen, ist das fast immer ein guter Tausch.
Drei Wochen bis zur ersten Version
Ein No-Code-MVP braucht einen Zeitplan, sonst wird es zum Bastelprojekt. Drei Wochen sind für die meisten Ideen realistisch, wenn du den Umfang hart begrenzt.
Woche eins gehört dem Kernablauf. Ein Kunde kommt rein, erledigt die eine Sache, für die er zahlt, und bekommt ein Ergebnis. Kein Profilbild, kein Passwort-Reset mit eigener Gestaltung, keine Einstellungen. Am Ende der Woche muss jemand Fremdes den Ablauf einmal durchklicken können, ohne dass du daneben sitzt.
In der zweiten Woche kommen Login, Bezahlung und die Benachrichtigungen dazu. Für die Bezahlung reicht oft ein Zahlungslink des Zahlungsdienstes statt einer eingebauten Kasse. Das spart Tage.
Woche drei ist für fünf echte Testnutzer reserviert. Nicht Freunde, sondern Leute aus deinen Interviews oder deinem Smoke Test. Du schaust zu, notierst, wo sie hängen bleiben, und behebst nur das. Neue Funktionen sind in dieser Woche verboten.
Klingt streng. Ist es auch. Der häufigste Grund, warum No-Code-Projekte sich über Monate ziehen, ist nicht die Technik, sondern dass der Baukasten so leicht macht, noch eine Kleinigkeit hinzuzufügen.
Noch einfacher: das Concierge-MVP
Manchmal ist selbst No-Code zu viel. Beim Concierge-MVP erledigst du die Leistung zunächst von Hand. Statt einer Plattform, die Angebote automatisch vergleicht, vergleichst du sie selbst und schickst das Ergebnis per E-Mail. Der Kunde bekommt das Ergebnis, das das Produkt später liefern soll, nur eben langsamer.
Das klingt unseriös, ist aber eine der ehrlichsten Formen der Validierung. Du lernst jeden Schritt kennen, den die Software später automatisieren muss, und siehst, für welchen Teil die Kunden wirklich zahlen. Es skaliert nicht. Muss es auch nicht.
Eine Mischform ist eine einfache Oberfläche aus Formular und Tabelle, hinter der du manuell arbeitest. Für den Kunden sieht es nach Software aus, für dich ist es Handarbeit mit Struktur.
Wann du umsteigen solltest
Es gibt keine feste Kundenzahl, ab der No-Code nicht mehr reicht. Es gibt aber Signale. Die Plattformkosten steigen schneller als der Umsatz. Kunden fragen nach Funktionen, die der Baukasten nicht hergibt. Ein großer Kunde verlangt eine Sicherheitsprüfung, die du nicht bestehen kannst. Oder du verbringst mehr Zeit mit Workarounds als mit Produktarbeit.
Wenn zwei dieser Punkte zutreffen, ist es Zeit für eine Eigenentwicklung. Dann hast du einen großen Vorteil gegenüber dem Start: Du weißt genau, was gebaut werden muss. Dein No-Code-MVP ist die beste Spezifikation, die es gibt. Was der Umstieg kostet, zeigt der Beitrag zu den Kosten eines MVP, und wie du die Anforderungen sauber aufschreibst, steht im Leitfaden zum Lastenheft für Software.
Für die Ablösung brauchst du entweder einen technischen Mitgründer oder einen externen Partner. Studios wie OnlineBuilders, die selbst SaaS-Plattformen bauen und betreiben, kennen den Weg von der Baukasten-Version zum eigenen Produkt.
Nächster Schritt: Schreib die fünf wichtigsten Abläufe deines Produkts auf und prüf für jeden, ob er aus Formular, Datenbank, Regel und Benachrichtigung besteht. Wenn ja, bau die erste Version mit einem Baukasten und setz dir eine Frist von drei Wochen.
Häufige Fragen
Kann ich mit No-Code eine echte App für den App Store bauen?
Einige Plattformen erzeugen inzwischen auch mobile Apps. Bubble etwa verlangt dafür einen bezahlten Tarif, um eine Live-Version in TestFlight oder die Stores zu bringen. Für ein erstes MVP ist eine mobil optimierte Web-App trotzdem oft der schnellere Weg.
Nehmen Investoren ein No-Code-MVP ernst?
In der frühen Phase zählen zahlende Kunden und Nutzungsdaten mehr als die Technik. Kritisch wird es erst, wenn Wachstum oder Sicherheitsanforderungen einen Umbau erzwingen. Dann solltest du einen Plan und ein Budget für die Ablösung zeigen können.
Ist No-Code DSGVO-konform?
Das hängt vom Anbieter ab, nicht von der Methode. Du brauchst einen Vertrag zur Auftragsverarbeitung nach Art. 28 DSGVO und bei US-Anbietern eine tragfähige Grundlage für die Datenübermittlung, etwa eine Zertifizierung unter dem EU-US Data Privacy Framework.
Was ist der Unterschied zwischen No-Code und Low-Code?
No-Code kommt ganz ohne Programmierung aus, Low-Code erlaubt eigene Code-Bausteine an Stellen, wo die Baukästen nicht reichen. Low-Code verschiebt die Grenzen, verlangt aber jemanden, der programmieren kann.
.jpg){kind=link}