Übernahme kaputter KI-gebauter Systeme: Rettung, Korrektur oder Migration
Übernahmeservice für kaputte, halbfertige Systeme aus KI-App-Buildern, Claude/ChatGPT oder 'System-Buildern': Bestandsaufnahme, Backup zuerst, dann korrigieren, migrieren oder neu bauen.
Demonstrationsprojekt
Ein Unternehmen hat für ein System bezahlt, das manuelle Arbeit entfernen sollte. Die Demo wirkte überzeugend, aber im Tagesgeschäft bricht es zusammen: Datensätze korrupten still, Fehler laufen in Schleifen, niemand kann etwas ändern, ohne etwas anderes zu brechen — und der ursprüngliche Erbauer ist verschwunden oder schlägt einen Neubau von Grund auf vor. Der Inhaber bleibt mit versenkten Kosten, einer operativen Abhängigkeit und ohne Ausweg zurück.
TL;DR
| Phase | Was Sie heute haben | Was Sie danach haben |
|---|---|---|
| Urteil | „Niemand kann mir sagen, ob das zu retten ist” | Eine schriftliche Antwort: korrigieren, migrieren oder stilllegen — mit den Kosten jedes Wegs |
| Daten | Leben in einem fragilen, halbfertigen System | Exportiert und gesichert, bevor irgendjemand etwas anfasst |
| Betrieb | Tägliche Umwege um kaputte Abläufe | Stabilisierte Abläufe, die Änderungen und neue Mitarbeiter überstehen |
| Eigentum | Der Erbauer hat die Schlüssel | Sie haben sie: Code, Daten, Dokumentation und Deploy-Zugang |
Diese Seite beschreibt den Service und die genaue Reihenfolge der Arbeit. Die verlinkten Artikel unten enthalten die verifizierten Preise und die Kostenrechnung dahinter.
Das Problem: „Es war zu 95 % fertig” — vor sechs Monaten
Das ist heute eine der häufigsten Situationen, die ich sehe. Ein System wurde mit einem KI-App-Builder gebaut (Replit, Lovable, Bolt, Bubble), komplett mit Claude, ChatGPT oder Cursor von einem freiberuflichen „System-Builder” generiert oder aus No-Code-Bausteinen zusammengesetzt — und die Demo hat tatsächlich funktioniert. Dann startete der echte Betrieb, und das Bild änderte sich:
- Es funktioniert für eine Person und bricht für das Team. Der Gründer kann es bedienen; ein neuer Mitarbeiter stolpert am ersten Tag über Fehler.
- Die Daten leben an fragilen Orten. Die Hälfte in Google Sheets, die andere Hälfte in der privaten Datenbank des Builders, ein Teil nur im Konto des KI-Anbieters. Niemand kann sagen, wo die Master-Kopie liegt.
- Fehler sind still. Doppelte Kunden, Aufträge, die zwischen Schritten verschwinden, Zahlen, die zum Monatsende nicht konsolidieren — Wochen später entdeckt, von Kunden oder vom Buchhalter.
- Jede Änderung bricht zwei andere Dinge. Es gibt keine Tests, keine Versionshistorie, die etwas bedeutet, und keine Dokumentation dessen, was der Code tatsächlich tut.
- Die Rechnungen laufen weiter. Builder-Abo, KI-Token-Verbrauch, Kosten pro Nutzer — während das dafür bezahlte System halb unbenutzt herumsteht.
- Der Erbauer ist weg — oder beantwortet jede Anfrage mit einem Angebot für einen Neubau von Grund auf.
Das versenkte Geld ist nicht das Schlimmste. Das Schlimmste ist die operative Abhängigkeit: Ihr Team leitet die tägliche Arbeit durch ein System, das niemand reparieren, erweitern oder sogar sicher abschalten kann.
Was ich übernehme
- KI-App-Builder-Projekte — Replit, Lovable, Bolt, Bubble und ähnliche, in jedem Zustand von „funktioniert fast” bis „mitten im Bau abgebrochen”.
- Mit Claude, ChatGPT oder Cursor generierte Systeme von einem Freelancer oder einem internen Enthusiasten, ohne technische Prüfung dahinter.
- No-Code-Systeme an ihrer Decke — AppSheet, Retool, Glide, Zapier/Make-Ketten, die unwartbar geworden sind.
- KI-Agenten-Prototypen, die Token verbrennen, unzuverlässig antworten oder nie fertig wurden.
Eine ehrliche Anmerkung: Manchmal lautet das Urteil “den Großteil behalten, zwei konkrete Dinge korrigieren” — und der Auftrag endet genau dort, günstig. Auch diese Antwort bekommen Sie, mit der Begründung schriftlich.
Wie eine Übernahme abläuft — die Reihenfolge meiner Arbeit
Schritt 1 — Ein 20-Minuten-Fit-Gespräch
Sie zeigen mir, was am meisten schmerzt und was Sie haben. Ich sage Ihnen sofort, ob es die Art von Projekt ist, die ich übernehme, und was der erste Blick darauf kostet. Keine Verpflichtung über dieses Gespräch hinaus.
Schritt 2 — Inventur und Zugänge
Vor jedem Urteil: eine vollständige Liste dessen, was tatsächlich existiert — Konten, Code, Tabellen, Datenbanken, Abos, Integrationen und wo die echten Daten leben. Bei halbfertigen Projekten spürt schon dieser Schritt üblicherweise Dinge auf, die der Inhaber nicht kannte (und Abos, an die sich niemand erinnerte).
Schritt 3 — Backup vor allem anderen
Ein vollständiger, schreibgeschützter Export jedes Geschäftsdatensatzes, bevor eine einzige Änderung gemacht wird. Was auch immer als Nächstes passiert — Korrektur, Migration oder die Entscheidung, das System stillzulegen — Ihre Daten sind bereits sicher und in Ihren Händen. Dieser Schritt birgt null Risiko für den Tagesbetrieb.
Schritt 4 — Audit und Urteil
Ich untersuche, wie das System gebaut ist und wo es tatsächlich bricht, und gebe Ihnen ein schriftliches Urteil:
- an Ort und Stelle korrigieren — was genau kaputt ist, was die Reparatur kostet und was danach weiterhin nicht stimmen wird;
- migrieren — was ein Neubau auf gesunder Grundlage kostet, in Geld und Kalenderzeit, mit Übernahme Ihrer bestehenden Daten;
- stilllegen — manchmal löst das System ein Problem, das Sie nicht mehr haben, und der richtige Schritt ist, es sauber abzuschalten.
Sie wählen den Weg mit echten Zahlen, nicht mit Hoffnung.
Schritt 5 — Stabilisierung
Welchen Weg Sie auch wählen, der Tagesbetrieb muss die Arbeit überstehen: Fehlerschleifen werden gestoppt, entgleiste KI-Rechnungen werden gedeckelt, und die zwei oder drei Abläufe, von denen Ihr Team am meisten abhängt, bekommen vorübergehende Stützen, damit niemand monatelang um ein kaputtes System herumarbeitet.
Schritt 6 — An Ort und Stelle korrigieren oder migrieren
Bei einer Korrektur: begrenzte Änderungen, jede verifiziert gegen eine Abnahmeliste in klarer Sprache, die Sie genehmigen — kein „glauben Sie mir, es funktioniert jetzt”.
Bei einer Migration: Die Daten werden sauber modelliert, mit Validierung bei jedem Schritt übertragen (Zeilenzahlen, Kontrollsummen, Stichproben, die Sie lesen können), und das alte und das neue System laufen parallel, bis sie konsolidieren. Ihr Team wechselt, wenn die Zahlen übereinstimmen — nicht vorher.
Schritt 7 — Umschaltung und Übergabe
Ein Konsolidierungsbericht aus dem Parallelbetrieb, eine Einführung für das Team, Dokumentation, der ein Nicht-Bauer folgen kann, und alles in Konten, die Ihnen gehören. Kein Lock-in: Jeder kompetente Entwickler kann es nach mir fortführen — das ist Absicht.
Was Sie bekommen
- Ein Urteil in Tagen, nicht Monaten — die eigentliche Frage der meisten Inhaber („Ist das überhaupt zu retten?”) bekommt früh eine schriftliche Antwort zu kleinen Fixkosten.
- Datensicherheit als Schritt eins, nicht als Nachgedanke.
- Ein System, das Ihr Team ohne Angst ändern kann — mit Tests als Sicherheitsnetz und einem Inhaber, der alle Schlüssel hält.
- Zombie-Abos und Token-Lecks gefunden und gestoppt — die den Auftrag oft von allein bezahlen.
Weiterführende Lektüre — die Zahlen hinter diesem Service
- Ihre Replit- oder Lovable-App ist nicht produktionsreif: Die wahren Kosten KI-gebauter Software — was in einer fünfstelligen Replit-Rettung steckte: was das 25-Dollar-Abo im Monat abdeckt und was es nie abdecken wird.
- AppSheets echte Kosten bei 20 Nutzern — und warum ein KI-Agent Sie nicht retten kann — die Sitzrechnung und warum Klick-only-Konfiguration nicht von einem KI-Agenten betrieben werden kann.
- Retool bei 20 Nutzern: Die Pro-Sitz-Rechnung, die niemand vor dem Abo durchrechnet — die Pro-Sitz- und metered-Run-Rechnung, die man vor dem Commitment an eine Builder-Plattform durchrechnen sollte.
- Geschäftsdaten für KI-Agenten vorbereiten — die Checkliste, die ich durchlaufe, bevor irgendein KI-Feature Ihre Daten anfasst.
- Hunderte Prompts später immer noch kein funktionierendes System — warum mehr Prompts einen kaputten Prozess nie repariert — und was es stattdessen tut.
Häufige Fragen
Ist mein Projekt zu retten, oder ist es ein Neubau? Genau das beantwortet das Audit. Manche Übernahmen enden mit einer zweiwöchigen Korrektur; andere sind ehrliche Neubauten mit Übernahme der alten Daten. Beide Antworten kommen mit Zahlen, und Sie wählen.
Der ursprüngliche Erbauer ist weg oder antwortet nicht. Können Sie trotzdem damit arbeiten? Meist ja — wenn Sie die Konten kontrollieren, auf denen das System läuft (oder sie zurückholen können). Der Inventur-Schritt stellt fest, was genau erreichbar ist und was nicht.
Müssen wir die aktuelle Plattform verlassen? Nein. Wenn die Plattform gesund ist und nur der Bau kaputt, ist die Korrektur an Ort und Stelle der günstigere Weg. Die Migration empfiehlt sich, wenn die Plattform selbst die Decke ist — und das Audit sagt, in welcher der beiden Situationen Sie sind.
Wollen Sie ein Urteil zu Ihrem feststeckenden Projekt?
Bringen Sie es in ein 20-Minuten-Fit-Gespräch. Sie verlassen das Gespräch mit der Antwort, ob Ihr System zu retten ist, was der realistische nächste Schritt ist und was er kostet — selbst wenn Sie mich nie beauftragen.