Kundenaufnahme-Checkliste für vererbten KI‑Code bei Agenturen

Warum Agenturen ein anderes Intake für vererbten KI‑Code brauchen

Viele KI‑erstelle Projekte sehen in der Demo toll aus. Der Happy‑Path klappt, die UI wirkt poliert und niemand bemerkt die Lücken, bis echte Nutzer kommen. Dann fängt die App an, auf scheinbar zufällige Weise zu versagen: Anmeldeschleifen, Zahlungen time‑outen oder Daten landen am falschen Ort.

Diese Diskrepanz ist vorhersehbar. Viele KI‑generierten Prototypen werden so gebaut, dass sie vollständig aussehen, bevor sie sicher oder zuverlässig sind. KI‑Tools können Bildschirme schnell zusammennähen, aber oft überspringen sie die langweilige Arbeit, die Software in Produktion stabil hält.

Die Fehlerquellen wiederholen sich oft projektübergreifend: Authentifizierung ist halb fertig oder zusammengeflickt, Secrets liegen im Repo oder in der falschen Umgebung, das Datenmodell ändert sich jede Woche, und Deployments hängen von manuellen Schritten ab, die nur eine Person kennt. Wenn Sie das Intake wie einen normalen Build führen (Feature‑Wünsche, Design‑Vorlieben, Timelines), übersehen Sie diese Risiken und erben unangenehme Überraschungen.

Ein gutes Intake für vererbten KI‑Code konzentriert sich weniger auf „was wollen Sie hinzufügen?“ und mehr auf „was kann nächste Woche brechen?" Klären Sie:

• Wo reale Nutzer heute hängen bleiben (nicht nur, was auf der Roadmap steht)
• Wer Repo, Hosting und Drittanbieter‑Konten kontrolliert
• Welche Daten gespeichert werden und was geschützt werden muss
• Was unbedingt funktionieren muss, damit das Geschäft läuft (Login, Checkout, E‑Mails)
• Was bereits „repariert“ wurde und von wem

Wenn Sie eine kurze Stabilisierung anstreben (meist 48–72 Stunden), ist der erste Job, die Blutung zu stoppen: die App zuverlässig machen, offensichtliche Sicherheitslöcher schließen und ein reproduzierbares Deploy einrichten. Verbesserungen kommen, sobald das Grundlegende steht.

Ein typisches Szenario: Ein Gründer sagt „ist im Grunde fertig“, weil die Demo‑Anmeldung funktioniert. Ihr Intake sollte bestätigen, was passiert, wenn 50 Nutzer sich anmelden, Passwörter zurücksetzen und die App von Grund auf deployed wird.

Ziel setzen: zuerst stabilisieren, dann verbessern

Wenn Sie vererbten KI‑Code übernehmen, verlieren Sie Vertrauen am schnellsten, wenn Sie neue Features versprechen, bevor die Grundlagen funktionieren. Setzen Sie ein klares Erstziel: Stabilisierung. Das gibt allen eine gemeinsame Definition von „fertig“ für die ersten 48–72 Stunden und macht Ihre Schätzung verteidigbar.

Definieren Sie „stabilisiert“ in einfachen Begriffen, die Ihr Kunde testen kann. Für die meisten Apps bedeutet das:

• Anmeldung und Registrierung funktionieren Ende‑zu‑Ende (inklusive Passwort‑Reset, falls genutzt)
• Der Hauptnutzerfluss läuft ohne Abstürze oder verwirrende Fehler
• Die App deployt auf dieselbe Weise jedes Mal (keine mysteriösen Schritte)
• Daten sind nicht offensichtlich gefährdet (keine exponierten Keys, kein weit offener Admin‑Zugang)

Ziehen Sie dann eine klare Trennlinie zwischen Stabilisierung, Rebuild und neuen Features.

• Stabilisierung stoppt die Blutung.
• Ein Rebuild ersetzt wackelige Fundamente.
• Neue Features warten, bis das Produkt zuverlässig ist.

Formulieren Sie diese Sprache im Intake, damit Ihr ganzes Team (und der Kunde) dieselben Definitionen nutzt.

Setzen Sie früh Guardrails: Timeline, Budgetgrenzen und wer die finale Entscheidung trifft, wenn es Tradeoffs wie „schnell reparieren“ vs. „sauber neu schreiben“ gibt. Nennen Sie einen Entscheider und eine Vertretung und stimmen Sie Reaktionszeiten ab, damit Sie während des Stabilitätsfensters nicht blockiert sind.

Wählen Sie schließlich einen Ort für Entscheidungen und Anforderungen. Es kann ein kurzes Dokument oder ein Ticket‑Board sein, aber es muss drei Fragen beantworten: Was soll die App heute tun, was zählt als Fehler und was ist bis nach der Stabilisierung nicht im Scope.

Schnelle Projekt‑Triage Fragen (10 Minuten)

Ein kurzes Triage‑Gespräch verhindert Überraschungen. Ziel ist nicht, jedes Detail zu verstehen, sondern schnell zu lernen, was Sie erben, was jetzt kaputt ist und ob ein 48–72‑Stunden‑Stabilisierungsfenster realistisch ist.

Nutzen Sie diese Fragen, um die Basics schnell zu klären:

• Wer hat es gebaut (Person oder Dienstleister), und welches KI‑Tool wurde verwendet (Lovable, Bolt, v0, Cursor, Replit usw.)? Was hat sich geändert, seit es zuletzt „funktionierte“?
• Wo läuft es heute: nur auf jemandes Laptop, auf einer Staging‑Seite, in Produktion oder nirgends? Wer hat Zugriff?
• Wer nutzt es gerade (falls überhaupt), und welche 1–2 Workflows müssen unbedingt funktionieren (Anmeldung, Checkout, Buchung, Admin‑Bearbeitungen)?
• Was genau scheitert gerade, in einfachen Worten? Fragen Sie nach einem aktuellen Beispiel, das ein Nutzer erlebt hat (Fehlermeldung, weiße Seite, falsche Daten).
• Gibt es Deadlines für eine Sales‑Demo, einen Pilot, eine Finanzierungsrunde oder eine Compliance‑Prüfung? Was passiert, wenn es um eine Woche verschoben wird?

Hören Sie auf Widersprüche. Wenn sie sagen „es hat letzte Woche funktioniert“, aber auch „niemand kann sich einloggen“, haben Sie schon eine Priorität: Authentifizierung und Zugang.

Beispiel: Ein Kunde braucht am Freitag eine Demo, die App läuft nur lokal und der letzte Entwickler hat „repariert“, indem er Secrets ins Frontend kopiert hat. Das ist kein Feature‑Sprint. Das ist ein kurzes Stabilisationsprojekt: ein deploybares Build herstellen, Secrets sperren und den Demo‑Pfad zuverlässig machen.

Zugang und Ownership: Kontrolle bekommen, bevor Sie am Code arbeiten

Bevor Sie ein Repo öffnen oder eine Timeline versprechen, stellen Sie sicher, dass der Kunde tatsächlich Kontrolle gewähren kann. Bei vererbtem KI‑Code ist das Chaos oft nicht nur im Code, sondern in Accounts, Tokens und halb fertigen Deployments, die niemand besitzt.

Starten Sie mit einer direkten Frage: Wo liegt der Code gerade? Wenn die Antwort „auf jemandes Laptop“ oder „in einem Tool wie Replit“ ohne klaren Owner lautet, betrachten Sie das als echtes Risiko. Zugang zuerst, Arbeit danach.

Mindestzugang, den Sie brauchen

Fordern Sie diese Dinge upfront an, damit Sie sicher arbeiten und später keine Überraschungen erleben:

• Repo‑Ort und ein echter Admin (GitHub, GitLab oder ein anderer Host)
• Deployment‑Zugang (wer kann in Produktion pushen, falls Produktion existiert)
• Liste der Umgebungen (dev, staging, prod) und ob etwas geteilt wird
• Methode der Secret‑Aufbewahrung (Env‑Dateien, Dashboard‑Variablen, Secret‑Manager) und wer Secrets rotieren kann
• Domain‑ und E‑Mail‑Eigentum (wer kontrolliert DNS und Transaktions‑Einstellungen)

Wenn der Kunde nicht mindestens einen Admin und einen sicheren Ort zum Ablegen von Secrets liefern kann, pausieren Sie. Am Code zu arbeiten ohne Ownership führt zu kaputten Logins, verlorenen Daten oder Produktionsausfällen.

Erwartungen zu Secrets und Deployments

Prototypen aus KI‑Tools haben oft exponierte Keys oder hartkodierte Passwörter. Selbst wenn die App „funktioniert“, gehen Sie davon aus, dass Secrets rotiert werden müssen.

Bestätigen Sie, wer ändern kann:

• Datenbank‑Passwörter und API‑Keys
• Auth‑Provider‑Einstellungen (OAuth‑Apps, JWT‑Secrets)
• Hosting‑Variablen und Build‑Einstellungen

Beispiel: Sie übernehmen ein Bolt‑Prototyp, das von einem persönlichen Account deployed wird und das Datenbankpasswort im Code steht. Der richtige Schritt ist, das Repo zu übertragen, das Deployment in einen agentur‑eigenen Workspace zu verschieben und Secrets zu rotieren, bevor Sie Features angehen.

Geschäftskritische Abläufe bestätigen (und was Sie fragen sollten)

Um Überraschungen zu vermeiden, einigen Sie sich auf die wenigen Abläufe, die unbedingt funktionieren müssen. So verhindern Sie, dass Sie das falsche Problem zuerst lösen.

Beginnen Sie mit Identity und Berechtigungen. „Login funktioniert" reicht nicht. Fragen Sie, wer was tun darf und wo diese Regel durchgesetzt wird. Wenn Berechtigungen nur im UI verborgen sind, kann ein Nutzer manchmal über ID‑Änderung oder direkte Endpunktaufrufe Einschränkungen umgehen.

Zahlungen und Abrechnung brauchen ebenfalls eine klare Fehler‑Story. Viele Prototypen behandeln nur den Happy Path. Klären Sie, was passieren soll, wenn eine Karte abgelehnt wird, ein Abo gekündigt wird oder eine Rückerstattung nötig ist, und wer diese Aktionen auslöst.

Klären Sie früh Datensensitivität. Wenn die App persönliche Daten, Gesundheitsdaten, Finanzdaten oder Daten über Minderjährige berührt, ändern sich Ihre Sicherheits‑ und Logging‑Entscheidungen schon am ersten Tag.

Bleiben Sie praktisch in den Fragen:

• Auth: Welche Rollen existieren (User, Admin, Staff) und was darf jede Rolle tun?
• Zahlungen: Was zählt als „bezahlt“, und was ändert sich bei Zahlungsausfall oder Rückerstattung?
• Daten: Welche sensiblen Felder existieren, und muss auf Anfrage etwas gelöscht werden?
• Integrationen: Was verbindet sich mit E‑Mail, CRM, File‑Storage, KI‑APIs oder Webhooks – und was bricht, wenn ein Dienst ausfällt?
• Admin‑Zugang: Gibt es ein „temporäres“ Admin‑Panel, ein geteiltes Passwort oder eine Hintertür, die noch genutzt wird?

Beispiel: Ein Gründer sagt „nur Admins können Kundendaten exportieren“. In vererbtem Code ist diese Regel manchmal nur ein Button, nicht eine serverseitige Berechtigungsprüfung.

Risikosignale, die Sie im ersten Call erkennen können

Einige Probleme zeigen sich, bevor Sie das Repo sehen. Ein gutes erstes Gespräch geht weniger ins Detail und mehr auf Signale: Läuft der Code irgendwo, ist der Zugang sauber und kann man dem, was Ihnen erzählt wird, vertrauen?

Achten Sie auf diese roten Flaggen:

• Läuft nur auf einer Personens Laptop, oder heißt es „wir können nicht mehr deployen“? Das deutet auf fehlende Env‑Setup, kaputte Build‑Steps oder undokumentierte Dienste hin.
• Secrets werden leger gehandhabt: API‑Keys im Chat, Tokens in einem geteilten Doc oder „nutzt einfach dieses Admin‑Passwort“. Gehen Sie von Exposure aus, bis das Gegenteil bewiesen ist.
• Auth ist inkonsistent: „Login funktioniert manchmal“, Rollen funktionieren nicht oder ein Nutzer sieht die Daten eines anderen.
• Bugs wirken zufällig und verschwinden beim Neuladen. Das kann auf flakigen State, Caching‑Probleme oder ungleiche Front‑/Back‑End‑Erwartungen hinweisen.
• Keine Tests, keine Logs und niemand weiß, was zuletzt geändert wurde. Ohne Audit‑Trail wird jede Reparatur Ratespiel.

Wenn Sie eines oder mehrere dieser Signale hören, nutzen Sie ruhige Nachfragen, um vage Schmerzen in klaren Scope zu verwandeln:

• „Wo läuft es heute, und wer kann es neu starten, wenn es ausfällt?"
• „Wie werden Secrets gespeichert, und wer hat gerade Zugriff?"
• „Welche Nutzeraktionen müssen jederzeit funktionieren, damit das Geschäft läuft?"
• „Wann hat es zuletzt funktioniert, und was ist kurz davor passiert?"

Beispiel: Die App wurde in Replit gebaut, das Deployment ist letzte Woche kaputtgegangen und sie teilen einen Stripe‑Key in Slack. Das ist Grund genug, Feature‑Requests zu pausieren und ein Stabilisierung‑zuerst‑Intake zu fahren, das Kontrolle, Sicherheit und reproduzierbares Deployment priorisiert.

Was Sie prüfen sollten, sobald Sie das Repo sehen (hochniveau, nicht‑technisch)

Sobald Sie Zugriff haben, müssen Sie nicht jede Datei lesen, um zu beurteilen, ob das Projekt sicher stabilisierbar ist. Ein kurzer Scan zeigt, ob es ein kleines Rescue oder ein tieferer Rebuild wird.

Starten Sie mit der Datenebene, denn Überraschungen dort greifen überall durch. Achten Sie auf doppelte Konzepte (z. B. users und app_users), unklare "Source of Truth"‑Felder und fehlende Migrationen. Wenn das Repo nicht erklärt, wie die Datenbank sich über die Zeit ändert, werden Releases schnell riskant.

Führen Sie dann einen grundlegenden Security‑Check durch, auch wenn Sie kein Security‑Experte sind. Prüfen Sie, ob Nutzereingaben sorgfältig behandelt werden, Dateiuploads beschränkt sind und etwas wie rohe SQL‑Ausführung oder untrusted Commands aussehen könnte. Scannen Sie nach Secrets im Repo (API‑Keys, DB‑Passwörter). Wenn Sie welche finden, gehen Sie von Leaks aus.

Schauen Sie sich außerdem die Struktur an. KI‑Prototypen kopieren oft dieselbe Logik an vielen Stellen. Das macht Fixes langsam und Bugs leicht wiederkehrend.

Eine kurze Checkliste, die meist die größten Risiken sichtbar macht:

• Gibt es eine klare Trennung Backend vs Frontend, oder ist alles vermischt?
• Sehen Sie dieselbe Logik an mehreren Stellen wiederholt?
• Wird Auth und Berechtigungen an einer Stelle gehandhabt, oder verteilt?
• Gibt es Error‑Reporting, oder schlägt die App still fehl?
• Existieren Basics wie Backups, Environment‑Configs und ein einfacher Deploy‑Pfad?

Erkennen Sie außerdem Performance‑Fallen früh. Wenn Seiten viele wiederholte API‑Aufrufe brauchen oder dieselben Daten mehrfach laden, sehen Sie langsame Seiten und Timeouts, sobald echte Nutzer kommen.

Ein einfacher 48–72‑Stunden‑Stabilisierungsplan (Schritt für Schritt)

Ein Stabilisierungsfenster ist kein Feature‑Sprint. Ziel ist, die App zuverlässig laufen zu lassen, die Blutung zu stoppen und allen eine klare Sicht auf die notwendigen Verbesserungen zu geben.

Der 5‑Schritte‑Plan

1. Get access, run it, and reproduce the worst failures. Sammeln Sie Repo‑Zugang, Hosting‑Zugang und Umgebungsvariablen. Starten Sie die App so, wie Nutzer es tun, und reproduzieren Sie die drei schlimmsten Fehler mit klaren Notizen.

2. Freeze scope und definieren Sie „done“ für die Stabilisierung. Vereinbaren Sie, dass neue Features warten. „Done" sollte konkret sein: Anmeldung funktioniert, der Hauptworkflow läuft und das Deployment erfordert keine manuellen Hacks.

3. Fixen Sie zuerst die Blocker. Priorisieren Sie alles, was Nutzer stoppt oder direkte Gefahr bedeutet: kaputte Auth, exponierte Secrets, abstürzende Seiten, fehlende Builds und Deployments, die nur auf einer Maschine funktionieren.

4. Fügen Sie grundlegende Schutzmaßnahmen hinzu, damit es stabil bleibt. Legen Sie simples Logging, klare Fehlermeldungen und ein paar Smoke‑Checks an, die denselben Ausfall wieder auffangen.

5. Übergeben Sie einen kurzen Report und die nächste Entscheidung. Fassen Sie zusammen, was repariert wurde, was noch riskant ist und was Sie empfehlen (Refactor, Security‑Härten oder Rebuild).

Häufige Intake‑Fehler, die später Explosionen verursachen

Der schnellste Weg, dass ein vererbtes KI‑Projekt schiefgeht, ist, es wie einen normalen Build zu behandeln. Ein Kunde will vielleicht am ersten Tag neue Features, aber wenn das Fundament wackelt, kann jede „kleine Änderung“ drei andere Dinge brechen.

Häufige Fehler sind:

• Liefertermine versprechen, bevor Sie ein Stabilisierungsfenster gefahren haben
• Tage auf Zugang warten (Repo, Hosting, DB) und dann Entscheidungen überstürzt treffen
• Erfolg definieren als „keine Bugs“ statt als kleine Liste geschäftskritischer Flows
• Oberflächliche Fixes ohne Rotation exponierter Secrets
• Änderungen in Produktion ohne Rollback‑Plan ausliefern

Beispiel: Ein Kunde wünscht eine „weitere Zahlungsmethode“ in einem Prototyp. Sie implementieren sie, Zahlungen funktionieren, aber ein geleakter API‑Key führt später zu Betrug und die Agentur bekommt die Schuld. Ein solides Intake beinhaltet ein Security‑Reset (Keys rotieren, Auth checken) und einen Rollback‑Plan, bevor Feature‑Arbeit beginnt.

Copy‑Paste‑Intake‑Checkliste (Quick Checks)

Nutzen Sie das, wenn Sie die Basics schnell bestätigen müssen und später keine Überraschungen wollen. Es ist für einen 10–15‑minütigen Übergabeanruf plus kurze Nacharbeit gedacht.

[ ] Access confirmed: repo + hosting + database + domain/DNS (who has admin?)
[ ] Third-party accounts listed: auth/email/payments/storage/analytics (who owns each?)
[ ] Security baseline: where secrets live today, how they will be rotated, and what data is sensitive
[ ] User roles: who can do what (admin, staff, customer) and which role is highest risk
[ ] Top 3 broken flows written down with a "done" definition for each
[ ] Deploy plan: how releases happen today and who can press the button
[ ] Observability: logs exist, error tracking is on, and someone will watch it after release
[ ] Backups: database backup status + restore test (or date of last known good backup)
[ ] 48-72 hour stabilization: what’s included (fix critical breakages, stop data leaks) vs excluded (new features, redesign)
[ ] Sign-off: one decision-maker for tradeoffs, plus a fallback if they are unavailable

Hinweis: Der Codeblock oben bleibt unverändert, damit Sie eine schnelle, kopierbare Checkliste für Calls haben.

Eine einfache Art, Erwartungen zu setzen: Stabilisierung bedeutet, dass die App an den wichtigsten Stellen nicht mehr versagt und offensichtliche Sicherheitslöcher geschlossen werden. Es bedeutet nicht, dass der Code hübsch, schnell oder skaliert‑bereit ist.

Beispiel: Wenn ein Kunde sagt „Checkout ist kaputt“, konkretisieren Sie auf einen testbaren Flow (Produktseite bis Zahlungsbestätigung) und einen einzigen Owner für das Zahlungs‑Konto. Ohne das können Sie den Code reparieren und trotzdem an fehlendem Zugang scheitern.

Beispiel‑Szenario: Vom vererbten Prototyp zur stabilen Veröffentlichung

Ein Kunde kommt mit einem Bolt‑Prototyp, den er zum Sammeln von Interesse genutzt hat. In Demos sieht die App gut aus, aber reale Nutzer können sich nicht einloggen. Manchmal dreht der Login‑Button ewig, manchmal werden Konten angelegt, aber nicht gespeichert.

Beim ersten Call fahren Sie ein Stabilisierung‑zuerst‑Intake. Ton bleibt neutral: Sie beurteilen nicht das Build, Sie klären, was nötig ist, damit es zuverlässig läuft.

In der Praxis bedeutet das meist:

• Bestätigen Sie die ein oder zwei Flows, die diese Woche funktionieren müssen.
• Holen Sie während des Calls Zugriff: Repo, Hosting, DB, Domain, Drittanbieter‑Services.
• Klären Sie, wo Secrets liegen und wer die Konten besitzt.
• Notieren Sie Risikofaktoren wie mehrere halb verdrahtete Auth‑Provider, hartkodierte Keys oder ein wackeliges Datenmodell.
• Setzen Sie das 48–72‑Stunden‑Ziel: stabilisieren, Guardrails ergänzen und ein kleines, sicheres Release ausliefern.

In 2–3 Tagen kann ein Team oft den Login stabilisieren, indem es Session‑Handling korrigiert, Umgebungsvariablen aufräumt und einfaches Error‑Logging hinzufügt, damit Fehler sichtbar werden. Offensichtliche Sicherheitsprobleme (exponierte Secrets) lassen sich patchen, und das meiste „zufällige“ Versagen verschwindet, sobald ein paar verstrickte Teile vereinfacht sind.

Was typischerweise zu einem Rebuild‑Vorschlag führt: eine Architektur, die Änderungen blockiert, unklare Ownership von Drittanbieter‑Konten oder ein Datenbankschema, das echten Gebrauch nicht unterstützt. Stellen Sie den Trade‑off offen dar: „Wir können das jetzt patchen, aber wenn Sie später schneller Features wollen, ist ein Rebuild günstiger als dauerhafte Flickarbeit."

Nächste Schritte: Intake wiederholbar machen und Überraschungen reduzieren

Behandeln Sie das Intake wie ein kleines Produkt. Wenn der Prozess jedes Mal gleich ist, verbringen Sie weniger Zeit mit Nachjagen und mehr Zeit mit dem, was wirklich zählt.

Senden Sie die Checkliste vor Kickoff. Bitten Sie den Kunden, sie ausgefüllt zurückzugeben und den Zugang bereitzustellen. Wenn Zugang „kommt“, ist das Projekt bereits in Verzug. Eine einfache Regel: Keine Arbeit beginnt, bevor Sie Repo und eine laufende Umgebung sehen.

Ein praktikabler Rhythmus ist, vor Planung neuer Features ein kurzes Stabilisationsfenster zu buchen. Tragen Sie 48–72 Stunden in den Kalender, um zu bestätigen, was existiert, was kaputt ist und was riskant ist. Danach können Sie Verbesserungen mit deutlich weniger Überraschungen schätzen.

Schreiben Sie Risiken in einfacher Sprache und holen Sie Prioritäten‑Signoff. Es geht nicht um Bürokratie, sondern darum, Verwirrung zu vermeiden, wenn ein „kleiner Fix“ später zu einem Sicherheitsproblem oder einem Rebuild wird.

Wenn Sie externe Hilfe für vererbten, KI‑generierten Code brauchen, bietet FixMyMess (fixmymess.ai) Codebasis‑Diagnose und Reparatur an, inklusive Security‑Härten, Refactoring und Deploy‑Vorbereitung. Sie bieten auch ein kostenloses Code‑Audit, um Probleme zu erkennen, bevor Sie sich auf einen Plan festlegen.