Kann KI deine Software bauen, ohne dich zu binden?

Ja — aber nur, wenn der Code, den die KI generiert, tatsächlich auf Infrastruktur deployt wird, die dir gehört, nicht in eine gehostete Black Box eines Anbieters. Die meisten “KI-App-Baukasten”-Produkte bestehen diesen Test leise nicht: Die Chat-Oberfläche ist beeindruckend, der Code kommt schnell heraus, und dann läuft er nur in der proprietären Runtime dieses Anbieters. Hörst du auf zu zahlen, zieht die App nicht mit dir um — sie hört auf, irgendwo zu existieren, wo du die Kontrolle hast. Die Frage, die wirklich zählt, ist nicht “hat KI das geschrieben?” Sie lautet “wo läuft es, und auf wessen Konto liegt es?”

Das Build-Modul von sSystm ist um genau diese zweite Frage herum entworfen. Dieser Beitrag geht durch, wie die Lock-in-Falle bei KI-App-Baukästen im Allgemeinen aussieht, wie Build sie umgeht und wie es mit der weiteren Human-in-Control- und MCP-Geschichte zusammenhängt, die jede KI-Aktion in der Plattform regelt.

Was bedeutet “KI-App-Baukasten-Lock-in” eigentlich?

Es ist derselbe vierteilige Lock-in, der jedes SaaS-Produkt plagt — Daten, Workflow, Integration, Vertrag — mit einer zusätzlichen Schicht obendrauf: Runtime-Lock-in. Ein KI-App-Baukasten, der nur in seine eigene gehostete Sandbox deployt, fügt eine fünfte Falle hinzu, die wohl am schwersten von allen zu entkommen ist, denn du hattest den Code nie in einer Form, in der du ihn überhaupt irgendwohin hättest mitnehmen können.

Konkret sieht das Muster so aus:

1. Du beschreibst eine App in einem Chatfeld.
2. Die KI des Anbieters generiert Code.
3. Der einzige Weg, diesen Code auszuführen, ist die gehostete Vorschau- oder Produktionsumgebung des Anbieters.
4. Wenn du kündigst, herabstufst oder der Anbieter diese Produktlinie einstellt, ist die App weg — nicht exportiert, nicht portierbar, einfach weg.

Die KI selbst ist nicht das Problem. Code-Generierung ist eine wirklich nützliche Sache, die ein Modell gut können sollte. Das Problem ist ein Geschäftsmodell, in dem die Runtime das Produkt ist und der generierte Code nur der Köder.

Wie funktioniert das Build-Modul von sSystm eigentlich?

Build ist ein Launcher, keine gehostete Black Box. Du öffnest es, beschreibst in einfacher Sprache, was du willst, und wählst eines von drei echten Frameworks: reines HTML, React oder einen Cloudflare Worker mit HTML-Ausgabe. Diese Beschreibung und Framework-Wahl erzeugt ein Projekt und übergibt dich an den Build-Editor — wo die eigentliche Code-Generierung, Live-Vorschau und Deploy-Schleife stattfindet.

Bewusst lebt Builds tiefe Bearbeitungsschleife — die Monaco-basierte Code-Ansicht, Live-Vorschau, Auto-Apply, Deploy-Button — an einem Ort: im Build-Editor selbst. Die KI-Assistant-Leiste anderswo im Workspace (dieselbe Leiste, mit der du eine Frage stellen oder eine Agent-Aktion ausführen würdest) ist der Einstiegspunkt, keine zweite Kopie des Editors. Das ist eine echte Design-Entscheidung, kein Zufall: eine tiefe Schleife, erreicht von einem leichtgewichtigen Launcher, statt einer über das Produkt verstreuten Build-Erfahrung.

Das Wichtige fürs Eigentum: Zu keinem Zeitpunkt bedeutet “Code generieren” “Code, der nur in sSystm läuft”. Es bedeutet ein echtes HTML-, React- oder Worker-Projekt — die Art von Codebasis, die jeder Entwickler öffnen, lesen und verändern könnte, ganz ohne sSystm im Spiel.

Wohin wird der KI-generierte Code tatsächlich deployt?

Auf dein eigenes Cloudflare-Konto — dasselbe, das den Rest deines BYOC-Workspace betreibt, nicht eine zentrale Multi-Tenant-Umgebung, die der Anbieter betreibt. Das ist dieselbe architektonische Entscheidung, die deine CRM- und Projektdaten von einer geteilten Anbieter-Datenbank fernhält: sSystms Kernversprechen ist, dass Kunden-Workspaces auf dem eigenen Cloud-Konto des Kunden bereitgestellt werden, und das Build-Modul macht keine Ausnahme für KI-generierte Projekte. Was die KI schreibt, wird genauso deployt wie alles andere.

Praktisch heißt das: Ein Projekt, das die KI für dich gebaut hat, ist erreichbar, einsehbar und veränderbar auf Infrastruktur, die bereits dir gehört — mit oder ohne geöffneten sSystm-Editor. Würdest du die Plattform je ganz verlassen, verschwindet die generierte App nicht mit deinem Abo, weil sie nie in einer anbietereigenen Runtime saß.

Das ist dieselbe Unterscheidung, die für SaaS-Vendor-Lock-in im Allgemeinen zählt: Ein Export-Button ist eine Momentaufnahme, Eigentum ist dort, wo das Ding bereits lebt. Builds Ausgabe lebt schon per Konstruktion auf deinem Konto, nicht durch einen einmaligen Migrationspfad, an den du dich erinnern musst.

Was hindert die KI daran, still etwas Destruktives zu tun?

Dieselbe Schranke, die jede andere KI-initiierte Aktion im Workspace regelt, kein Sonderfall für Code-Generierung. Cloudflare-gerichtete Operationen, die destruktiv sein könnten — Ressourcen bereitstellen, Einstellungen ändern, Zugriffsregeln anfassen — werden als ausstehende Infrastruktur-Operationen angelegt und warten, bis ein Mensch sie prüft und freigibt, bevor irgendetwas ausgeführt wird. Nichts läuft still im Hintergrund, weil eine KI entschieden hat, dass es das sollte.

Diese eine Regel — die KI schlägt vor, ein Mensch gibt frei — macht “KI ist der Baumeister” zu einem sicheren Satz statt einem beängstigenden. Sie gilt, ob die KI eine Komponente über Build generiert, anderswo im Workspace eine Agent-Aktion ausführt oder eine Infrastruktur-Änderung anfragt. Es gibt keinen leiseren, weniger überwachten Pfad, den KI-generierter Code nehmen darf, nur weil er aus einem Chat-Prompt stammt.

Wie passt MCP zu “KI baut deine Software”?

Build beantwortet “kann die KI mir eine deploybare App generieren?” MCP beantwortet eine verwandte, aber andere Frage: “kann die KI, der ich schon vertraue — Claude oder ein beliebiger anderer MCP-Client — tatsächlich auf meinen echten Workspace-Daten arbeiten, mit echten Werkzeugen, keiner Spielzeug-Demo?” sSystm stellt seinen gesamten Workspace über MCP bereit — CRM, Projekte, Design-System, Dokumente, Kalender — als eine Menge typisierter Werkzeuge und lesbarer Ressourcen, sodass ein externer KI-Assistent dieselben Daten liest und schreibt, mit denen dein Team arbeitet, geregelt durch dieselbe Human-Approval-Regel, die auch Builds Infrastruktur-Operationen regelt.

Zusammengenommen hat die KI-Geschichte des Workspace drei konsistente Modi, alle von derselben Assistant-Leiste erreichbar: Ask (Chat, verankert in deinen echten Daten), Act (Agent-Aktionen, angelegt und freigegeben) und Build (beschreibe eine App, wähle ein Framework, erhalte ein echtes deploybares Projekt). Keiner der drei hängt von einer proprietären KI-Modellwahl oder einer geschlossenen Runtime ab — der Workspace stellt echte Werkzeuge und echte Infrastruktur bereit, und welche KI du auch nutzt, sie ist es, die die Arbeit macht.

Ist das Zahlen für KI-Credits selbst eine neue Art von Lock-in?

Es ist der eine Teil des Modells, der wirklich monetarisiert wird, und es lohnt sich, direkt zu sein: sSystm verkauft KI-Nutzung über ein vorausbezahltes Credit-Guthaben weiter, pro Aufruf gemessen, statt sie unsichtbar in ein pauschales Abo zu falten. Das sind echte Kosten, die du für echte Nutzung zahlst — es ist nicht dasselbe wie Runtime-Lock-in, denn das, wofür du zahlst (Tokens, die beim Generieren deines Codes verbraucht werden), wird einmal verbraucht und hält dein Ergebnis danach nicht als Geisel. Die App, die Build für dich generiert hat, läuft weiter auf deinem eigenen Cloudflare-Konto, egal ob du das Guthaben morgen wieder auflädst. Du kannst aufhören, KI-Credits zu kaufen, und alles behalten, was du bereits gebaut hast — das ist der Test, den ein wirklich nicht-bindendes KI-Feature bestehen muss, und das ist eine andere Frage als die, ob du mit der Messung selbst zufrieden bist.

KI-App-Baukasten vs. BYOC-Build-Modul

	Typischer KI-App-Baukasten	Build-Modul von sSystm
Wo generierter Code läuft	Nur in der gehosteten Runtime des Anbieters	Dein eigenes Cloudflare-Konto
Was du bekommst	Eine Live-Demo in ihrem Produkt	Echtes HTML-/React-/Worker-Projekt
Wenn du aufhörst zu zahlen	Die App ist weg	Die App läuft weiter — sie liegt auf deiner Infrastruktur
Destruktive KI-Aktionen	Unterschiedlich, oft still	Als ausstehend angelegt, vom Menschen freigegeben
Welche KI die Arbeit macht	Das Modell, das der Anbieter gewählt hat	Jede MCP-kompatible KI, die du verbindest, plus der eingebaute Build-Fluss
Kostenmodell	Oft gebündelt, undurchsichtig	Vorausbezahlte Credits, pro Aufruf gemessen

Wie probierst du das tatsächlich aus?

1. Öffne den Build-Modus in der Assistant-Leiste und beschreibe in einfacher Sprache die App, die du willst.
2. Wähle ein Framework — HTML für etwas Einfaches, React für eine interaktive App oder einen Cloudflare Worker, wenn du serverseitige Logik brauchst.
3. Lande im Build-Editor, wo das Projekt bereits aufgesetzt wurde und die Generierung live weiterläuft.
4. Deploye — das Projekt geht auf dein eigenes Cloudflare-Konto, dieselbe BYOC-Infrastruktur, die den Rest deines Workspace betreibt.

Wenn du lieber über deinen eigenen KI-Client statt über den eingebauten Assistenten arbeitest, ist derselbe Workspace über MCP erreichbar — siehe den vollständigen Modulkatalog für alles Weitere, das eine KI, deine oder die von sSystm, erreichen kann, sobald sie verbunden ist.