Lovable, Bolt, v0 und Co.: warum aus einem Prototyp nie ein Unternehmenssystem wird

KI-Baukästen machen heute aus einem einzigen Satz in Minuten einen brauchbaren Bildschirm. Was sie nicht machen, ist alles andere - Daten, Berechtigungen, Betrieb. Wo genau die Grenze zwischen Prototyp und einem System verläuft, auf dem eine Firma wirklich läuft.

Marek Raja

Wenn Sie im letzten Jahr ein Video gesehen haben, in dem jemand einen Satz tippt und dreißig Sekunden später eine App auf dem Bildschirm hat, dann haben Sie ein Werkzeug wie Lovable, Bolt oder v0 gesehen. Das ist kein Taschenspielertrick. Sie können das wirklich, und sie sind wirklich so schnell.

Das Problem beginnt in dem Moment, in dem Sie diesen Bildschirm am Montagmorgen fünf Kollegen geben und sagen wollen: ab heute arbeiten wir darin.

Was diese Werkzeuge tatsächlich leisten

Ein KI-Baukasten nimmt eine Beschreibung in normaler Sprache und erzeugt daraus Quellcode - meist eine Webseite oder eine App mit einigen Bildschirmen. Das Ergebnis sieht gut aus, läuft im Browser und lässt sich sofort herzeigen.

Wo diese Werkzeuge wirklich stark sind:

  • Prototyp für ein Meeting. Sie müssen zeigen, wie eine Bestellseite aussehen könnte, und wollen keinen Designer für drei Tage bezahlen.
  • Eine Idee prüfen. Sie wollen wissen, ob der Ablauf in Ihrem Kopf für andere Menschen Sinn ergibt, bevor Sie investieren.
  • Einmalige Dinge. Ein Rechner, eine Mikro-App für eine Kampagne, etwas, das Sie in einem Monat wegwerfen.

Das alles sind legitime Aufgaben, und es hat keinen Sinn, sie kleinzureden. Die Frage ist, was passiert, wenn dasselbe Werkzeug die Rolle des Systems übernimmt, in dem die Firma ihre Aufträge führt.

Drei Dinge, die ein Prototyp nicht hat

1. Daten, die irgendwo wohnen

Ein erzeugter Bildschirm kann eine Tabelle anzeigen. Er klärt aber nicht, wo diese Tabelle physisch liegt, wer sie sichert, was passiert, wenn sie jemand versehentlich löscht, und wie Sie die Daten in zwei Jahren wieder herausbekommen.

Ein Unternehmenssystem steht und fällt mit dem Datenmodell - damit, dass ein Auftrag weiß, zu welchem Kunden er gehört, eine Rechnung zu welchem Auftrag, und ein Stundennachweis, wer ihn erfasst hat. Das ist kein Bildschirm. Das ist die Schicht darunter.

2. Wer was sieht

Im Prototyp sehen alle alles, denn ein Prototyp hat einen Nutzer - Sie. In einer echten Firma soll eine Aushilfe ihre Schichten sehen, ein Vertriebler die Preise seiner Aufträge und die Buchhaltung alles außer den Personalkosten der Kollegen.

Berechtigungen sind keine Funktion, die man später nachrüstet. Es sind Regeln, die in jeder Ansicht, jedem Export und jeder E-Mail gelten müssen, die das System verschickt.

3. Betrieb

Wer hostet die App. Wer zahlt den Server. Was passiert, wenn sie am Freitagabend ausfällt. Wer spielt das Sicherheitsupdate einer Bibliothek ein, von der Sie nie gehört haben. Wer stellt die Daten aus dem Backup wieder her, wenn es so weit ist.

Beim Prototyp sind das abstrakte Fragen. Bei einem System mit Aufträgen im Millionenbereich sind es Fragen, die jemand namentlich beantworten muss.

Den Bildschirm erzeugen beide Werkzeuge. Der Unterschied liegt darunter.

Ein Prototyp beantwortet die Frage „wie könnte das aussehen“. Ein System muss auch beantworten, wo die Daten liegen, wer sie hostet und wer die Preise sieht.

Prototyp vs. Produktivsystem

KriteriumKI-BaukastenProduktivsystem
Zeit bis zum ersten ErgebnisMinutenMinuten bis Stunden
Was mit den DatenIhre Sache (Datenbank, Hosting, Backups)Teil der Plattform
Berechtigungen und RollenVon Hand geschriebenEinstellung, keine Entwicklung
Änderung nach einem halben JahrNeuer Prompt, neuer Code, neues ReviewFeld oder Automatisierung anpassen
Wer es pflegen kannWer Code lesen kannJeder im Team
Wofür es taugtPrototyp, Demo, EinmaligesDas System, auf dem die Firma steht

Wo die Grenze verläuft

Eine praktische Faustregel: ein Prototyp ist in Ordnung, solange er keine Daten enthält, um die es Ihnen leidtäte.

Sobald echte Aufträge, Kundenkontakte, Stundennachweise oder Rechnungen in die App fallen, wechseln Sie die Kategorie. Es geht nicht darum, dass der Baukasten ein schlechtes Werkzeug wäre - es ist ein anderes Werkzeug für eine andere Aufgabe, ähnlich wie eine Skizze etwas anderes ist als eine Ausführungsplanung.

Ein Test mit einer Frage

Fragen Sie sich: Wenn diese App morgen nicht mehr existierte, wie viel Arbeit würde es uns kosten, sie zu ersetzen? Lautet die Antwort „eine Stunde“, machen Sie ruhig mit dem Prototyp weiter. Lautet sie „eine Woche, und wir wissen nicht, wo die Daten sind“, brauchen Sie ein System.

Was das praktisch heißt

Das sinnvollste Vorgehen, das wir bei Firmen sehen, die beides durchgemacht haben:

  1. Prüfen Sie die Idee mit einem Prototyp. Schnell, günstig, gern im Baukasten. Sie erfahren, ob der Ablauf überhaupt Sinn ergibt.
  2. Bauen Sie das Bewährte auf einer Plattform. Datenmodell, Berechtigungen und Automatisierungen sind dann kein Code mehr, sondern Konfiguration.
  3. Werfen Sie den Prototyp weg. Ohne Wehmut. Er hat getan, wofür er da war.

Ein genauerer Vergleich der Ansätze, auch mit Low-Code, steht in Low-Code vs. No-Code vs. Vibe Coding. Was mit erzeugtem Code nach einem Jahr passiert, beantwortet Die KI schreibt Ihnen die App. Wer repariert sie?. Das gesamte Thema von den Grundbegriffen bis zu den Grenzen von No-Code fasst der komplette Leitfaden zu No-Code und KI-Entwicklung zusammen.

Häufige Fragen zu KI-Baukästen

Sind Werkzeuge wie Lovable oder Bolt also nutzlos?

Überhaupt nicht. Sie sind sehr gut in dem, wofür sie gebaut wurden - schnell einen funktionierenden Bildschirm oder Prototyp erzeugen. Das Problem entsteht nur, wenn aus einem Prototyp still und leise das System wird, auf dem eine Firma läuft, ohne dass jemand Daten, Berechtigungen und Betrieb geklärt hat.

Kann ich den erzeugten Code nicht einfach in Betrieb nehmen?

Können Sie, aber damit übernehmen Sie die Rolle des Software-Betreibers: Hosting, Backups, Sicherheitsupdates und Fehlerbehebung. Für eine Firma ohne eigenen Entwickler ist das meist teurer und riskanter als das Schreiben der App selbst.

Woran erkenne ich, dass ich ein System und keinen Prototyp brauche?

An den Daten. Sobald echte Aufträge, Kunden oder Stundennachweise in der App leben und ihr Verlust ein echtes Problem wäre, brauchen Sie eine Plattform, die dafür Verantwortung übernimmt.

Beschreiben Sie, was das System können soll.

Apexloop baut die App um Sie herum