Sieben Tage bis zum Versand

15. Februar 2026. Ein Samstag. Wir hatten eine Unternehmensplattform, die unsere B2B-Kunden seit Monaten nutzen. Sandboxed AI-Agenten, 97 LLM-Modelle, Workspace-Management, der ganze Stack. Was wir nicht hatten, war ein Produkt, für das sich eine einzelne Person anmelden und es in weniger als einer Minute nutzen konnte.

Wir hatten die Zahlen von OpenClaw eine Weile beobachtet. 157.000 GitHub-Sterne. Tausende von täglich aktiven Nutzern. Eine Community, die weiter wächst, egal wie viele Sicherheitswarnungen veröffentlicht werden. Die Nachfrage ist echt und sie lässt nicht nach. Die Leute wollen autonome AI-Agenten. Sie wollen ein Tool installieren, es auf ein Problem richten und dann weggehen.

Aber wir sahen immer wieder dasselbe Muster in unseren Unternehmensvertriebsgesprächen. Interessenten sagten: „Wir haben OpenClaw intern ausprobiert. Es war großartig, bis jemandes Agent rm -rf auf einem gemeinsamen Volume ausgeführt hat.“ Oder: „Wir liebten die Flexibilität, konnten aber die Sicherheitsüberprüfung nicht bestehen.“ Der Appetit war da. Das Vertrauen nicht.

Da hat es Klick gemacht. Wir hatten bereits die sichere Version. Unsere Unternehmensplattform führt jede Agentenausführung in einem isolierten E2B-Sandbox aus. Kein direkter Systemzugriff, keine Klartext-API-Schlüssel, kein Agent, der alles tun kann, was er will. Der Kompromiss ist ein bisschen weniger Flexibilität — man kann keine beliebigen Systempakete installieren oder sein Home-Verzeichnis einbinden. Aber man kann auch nicht versehentlich sein Dateisystem löschen oder Anmeldeinformationen an eine bösartige Fähigkeit weitergeben.

Die Frage war nicht, ob wir ein Verbraucherprodukt entwickeln sollten. Es war, ob wir die Unternehmenskomplexität schnell genug reduzieren konnten, um eines zu versenden. Wir gaben uns sieben Tage.

Was gestrichen wurde

Die ersten zwei Tage drehten sich um Subtraktion, nicht um Addition.

Gruppen kamen zuerst. In der Unternehmensversion gehört jeder Nutzer zu einer Organisation, jede Organisation hat Rollen, jede Rolle hat Berechtigungen. Für ein Verbraucherprodukt bist du einfach du. Ein Konto, ein Workspace, deine Sachen. Wir haben das Variantensystem entwickelt, um diese gesamte Ebene zur Build-Zeit zu entfernen — der Code existiert weiterhin für Unternehmenskunden, er wird nur nicht in das Verbraucher-Bundle kompiliert.

Es folgten interne Systemintegrationen. Jira-Webhooks, Confluence-Seitenimporte, benutzerdefinierte SSO-Flows — alles nur für Unternehmen. Die Verbraucher-Version verbindet sich mit den Tools, die Einzelpersonen tatsächlich nutzen: Gmail, Slack, Notion, GitHub.

Das Admin-Dashboard blieb nur für Unternehmen. Kein Verbraucher benötigt ein Nutzungsanalytik-Panel mit Teamaufteilungen. Sie brauchen eine Seitenleiste, die ihr Guthaben anzeigt, und einen Button, um mehr zu kaufen.

Wir hätten das Repo forken können. Jedes Instinkt sagt, fork es, beweg dich schnell, räum später auf. Das haben wir nicht getan. Stattdessen haben wir die Code-Pfad-Trennung in die bestehende Codebasis integriert. LikeClaw, Dashboard, FulDive — drei Produkte, ein Repo, unterschiedliche Umgebungsconfigs. Jeder Sicherheitspatch, jeder Performance-Fix, jedes neue Modell trifft alle Varianten gleichzeitig. Der Preis ist ein bisschen mehr Komplexität im Build. Der Vorteil ist, dass wir niemals eine einzige Zeile zurückportieren müssen.

Verbraucherabrechnung von Grund auf

Unternehmenskunden zahlen per Rechnung. Net 30, Bestellungen, das ganze Ritual. Verbraucher zahlen mit ihrem Daumen auf einem Handy-Bildschirm.

Wir hatten bereits Stripe und Google Play aus früheren Arbeiten eingerichtet. Aber Apple würde nicht warten. Wenn du iOS-Nutzer dazu bringen willst, Credits zu kaufen, brauchst du die App Store-Belegverifizierung, eine UI für Kreditpakete, die neben der Play Store-Version Sinn macht, und eine automatische Aktualisierung, damit die Seitenleiste aktualisiert wird, sobald eine LLM-Antwort eintrifft.

Marina baute die gesamte Apple Store-Abrechnungsintegration in drei Tagen. Verifizierungsendpunkt. Kreditpaket-Kacheln. Testbenutzerkonfigurationen für die App Store-Überprüfung. Drei Abrechnungsanbieter, ein einheitliches Kreditsystem. Die Art von Infrastruktur, die unsichtbar ist, wenn sie funktioniert, und katastrophal, wenn nicht.

Ein-Klick-Anmeldung

Unternehmenskunden erhalten einen Vertriebsanruf, einen Vertrag, ein bereitgestelltes Konto. Verbraucher erhalten einen Google-Button.

Google OAuth wurde am 18. Februar integriert. Der Ablauf: Frontend leitet an Backend weiter, Backend kümmert sich um den Google-Handshake, Callback leitet mit einem Sitzungs-Cookie zurück zum Frontend. Ein @Public-Dekorator am Callback-Endpunkt, damit die Auth-Middleware eine nicht authentifizierte OAuth-Weiterleitung nicht ablehnt. Token-Caching mit Datumsrevivern, damit abgelaufene Anmeldeinformationen nicht durchschlüpfen.

Zwei Tage Arbeit. Das Ergebnis: ein Klick zur Anmeldung. Keine Passwörter, keine E-Mail-Verifizierung, kein „Überprüfe dein Postfach“. Der Unternehmens-SSO-Flow hat zwölf Konfigurationsfelder. Der Verbraucher-Flow hat einen Button.

Das Onboarding-Problem

Hier wird der Übergang von Unternehmens- zu Verbraucherprodukten schwierig.

Unternehmensnutzer werden von Menschen eingearbeitet. Ein Solutions Engineer führt sie durch die Einrichtung des Workspaces, verbindet ihre Integrationen, konfiguriert ihren ersten Agenten. Es dauert einen Nachmittag. Niemand beschwert sich, weil der Vertrag bereits unterschrieben ist.

Verbrauchernutzer haben sechzig Sekunden, bevor sie gehen. Vielleicht weniger.

Das alte Onboarding war ein modales Overlay. Es erschien, fragte dich, was du tun wolltest, und verschwand. Gut für jemanden, der bereits ein Meeting über das Produkt hatte. Nutzlos für jemanden, der gerade auf einen Link geklickt hat.

Wir haben es herausgerissen. Wir haben eine dedizierte /onboarding-Route mit einem mehrstufigen Wizard gebaut. Der Hauptbildschirm zeigt Szenario-Karten: Gmail-Automatisierung, tiefgehende Recherche, Code-Analyse. Jede Karte hat einen Verpflichtungschip — „Keine Einrichtung“, „OAuth erforderlich“, „API-Token“ — damit du weißt, wofür du dich anmeldest, bevor du zusagst. Der Skill-Auswahlbildschirm zeigt kuratierte Skills mit Downloadzahlen, Sternebewertungen und Autoreninformationen. Soziale Beweise in die ersten sechzig Sekunden eingebaut.

Der Trick, der alles zusammenfügte: Auto-Submit. Wenn du den Onboarding-Flow abschließt, wird dein ausgewähltes Szenario direkt als Eingabeaufforderung in den Chat injiziert. Kein Kopieren und Einfügen, kein „Was jetzt?“-Moment. Du beendest das Onboarding und der Agent arbeitet bereits.

Neun Sprachen, ein Tag

21. Februar. Marina fügte dem Frontend Deutsch, Spanisch, Französisch, Koreanisch, Portugiesisch und Brasilianisches Portugiesisch hinzu. Sechs Sprachen an einem einzigen Tag. Das klingt unmöglich, bis du realisierst, dass unsere i18n-Infrastruktur bereits mit Englisch, Russisch, vereinfachtem Chinesisch und traditionellem Chinesisch auf Herz und Nieren getestet wurde. Die Muster waren vorhanden. Die Übersetzungspipeline war bewährt. Sechs weitere hinzuzufügen war mechanisch, nicht kreativ.

Unternehmenskunden sprechen größtenteils Englisch. Verbraucher sprechen, was sie sprechen. Plattformparität ist nicht optional, wenn du global am ersten Tag launchen willst.

Der Sicherheitscheck

Der Tag vor dem Launch ist nicht der Zeitpunkt, um eine Sicherheitsanfälligkeit zu entdecken. Es ist die Zeit, um zu überprüfen, dass du keine hast.

Wir haben eine vollständige Prüfung der Sandbox-Grenze durchgeführt. Die kritische Regel: Echte API-Schlüssel dürfen niemals in die E2B-Sandbox gelangen. Weder der OpenRouter-Schlüssel noch irgendwelche Anbieteranmeldeinformationen. Die Sandbox erhält ein kurzlebiges JWT, das über unseren LLM-Proxy geleitet wird. Wenn die Sandbox kompromittiert wird, erhält der Angreifer ein Token, das abläuft, bevor er irgendetwas damit tun kann.

Das war für den Verbraucherlaunch wichtiger als je zuvor für Unternehmen. Unternehmenskunden laufen auf privater Infrastruktur hinter Firewalls. Verbraucher nutzen gemeinsame Infrastruktur im öffentlichen Internet. Die Angriffsfläche ist größer. Die Sicherheit muss strenger sein.

Was ausgeliefert wurde

97 LLM-Modelle über OpenRouter verfügbar. Neun Sprachen. Drei Abrechnungsanbieter. OAuth-Anmeldung. Ein neuer Onboarding-Wizard. Cloudflare Pages-Frontend. StackSmith-Backend. Sandbox-Sicherheitsverstärkung. Und 15 Prompt-Evaluierungsszenarien, die sicherstellen, dass die AI nicht zurückfällt, während wir alles um sie herum neu aufbauen.

Sieben Tage. Zwei Entwickler. Ein Produkt, das von „Unternehmensplattform für B2B-Kunden“ zu „Verbraucher-SaaS, für das sich jeder in dreißig Sekunden anmelden kann“ wurde.

Die Unternehmensversion hat kein einziges Feature verloren. Sie hat jede Verbesserung gewonnen, die wir für Verbraucher gemacht haben — schnelleres Onboarding, bessere Skill-Entdeckung, striktere Sandbox-Sicherheit. Das Variantensystem bedeutet, dass sich die beiden Produkte gegenseitig vorantreiben. Was wir für Einzelpersonen bauen, macht die Unternehmensversion besser. Was unsere Unternehmenskunden verlangen, macht die Verbraucher-Version robuster.

OpenClaw hat der Welt gezeigt, dass die Leute AI-Agenten wollen. Daran wollen wir nicht rütteln. Wir bieten die gleiche Fähigkeit mit einem anderen Vertrag an: dein Agent läuft in einer Sandbox, deine Schlüssel bleiben verschlüsselt, dein Dateisystem bleibt intakt. Ein bisschen weniger Flexibilität. Viel mehr Schlaf in der Nacht.

Der Übergang von Unternehmens- zu Verbraucherprodukten ist kein Pivot. Es ist eine zweite Front. Gleiche Armee, gleiche Waffen, breiteres Schlachtfeld.

LikeClaw ist live. Das Unternehmensdashboard wird weiterhin aktualisiert. Am Montag beginnen wir, für beide zu bauen.