Vorlage für einen Remediation‑Brief, den Gründer an Entwickler übergeben können

Was ein Remediation-Brief leistet (ganz ohne Fachsprache)

Ein Remediation-Brief ist eine kurze Notiz, die ein Problem so klar beschreibt, dass ein Entwickler es ohne Raten beheben kann. Es ist der Beleg für einen Fix: was kaputt ist, was „behoben“ bedeutet und wie Sie das überprüfen.

Er ist kein Produkt-Spec, kein langes Design-Dokument und kein Ort, um Optionen zu diskutieren. Er ist auch kein Bug-Report, der bei „Login ist kaputt“ stehen bleibt. Es geht um Klarheit, nicht um Kommentare.

Ein Brief zahlt sich aus, wenn das Problem Nutzer oder Umsatz betrifft, schwer reproduzierbar ist, bereits einen „Fix“ hatte, der nicht gehalten hat, von mehreren Personen berührt wird (Dev, QA, Auftragnehmer) oder exakte Resultate braucht (nicht nur „besser machen“).

Eine kurze Nachricht reicht für eine winzige, offensichtliche Änderung (z. B. Tippfehler) mit geringem Risiko. Für alles, das sich zum Scope-Creep auswachsen oder Tage an Rückfragen auslösen kann, spart ein Brief Zeit.

Entwickler:innen brauchen vier Dinge, um sauber zu arbeiten: was jetzt passiert, was stattdessen passieren soll, wie dringend es ist und wie man bestätigt, dass es erledigt ist. Fehlen diese Angaben, verlangsamt das die Arbeit, weil Leute Fragen stellen oder Lücken mit Annahmen füllen. Annahmen sind die Quelle von Überraschungen.

Gründer profitieren doppelt von einem guten Brief: weniger Überraschungen und ein saubererer Umfang. „Behoben“ wird eine gemeinsame Definition, sodass Sie nicht aufgrund von Gefühlen abnehmen.

Beispiel: „Users can’t log in“ ist vage. Ein Brief, der sagt „Google-Login springt auf mobile Safari nach dem Login wieder auf /login zurück, begann nach dem letzten Deploy, und ist behoben, wenn der Nutzer auf /dashboard landet und nach einem Refresh eingeloggt bleibt“, gibt dem Entwickler eine klare Richtung.

Wenn Sie KI-generierten Code übernommen haben, der sich unvorhersehbar verhält, hilft so ein Brief Teams wie FixMyMess ebenfalls, schneller zu diagnostizieren und zu reparieren, weil das Zielergebnis unmissverständlich ist.

Bevor Sie anfangen: Einen einzigen Fehler abgrenzen

Starten Sie mit einer Regel: ein Problem pro Brief. Wenn Sie „Login ist kaputt“ mit „E-Mails gehen nicht raus“ und „Dashboard ist langsam“ mischen, verbringen Entwickler:innen Zeit damit, den Haufen zu sortieren, statt das höchstwirksame Problem zu beheben.

Wählen Sie das eine Thema, das gerade am meisten schadet. Einen zweiten Brief können Sie später erstellen. Kleinere Scope sind leichter zu testen und verursachen seltener neue Bugs.

Benennen Sie zuerst den Produktbereich, damit alle über denselben Teil der App sprechen. Verwenden Sie einfache Labels wie auth, payments, onboarding, admin oder API. „Users can’t log in“ ist klarer als „die Seite ist kaputt“.

Sagen Sie dann, wer betroffen ist und wie häufig es passiert. Vermeiden Sie „es scheint zufällig zu sein“. Wenn Sie keine genauen Zahlen haben, schätzen Sie ehrlich: „Passiert bei neuen Nutzern etwa halb so oft“ ist immer noch nützlich.

Um das Problem schnell zu fassen, beantworten Sie:

• Produktbereich: Wo passiert das?
• Betroffene Nutzer: Wer trifft es (neue Nutzer, Admins, zahlende Kunden)?
• Häufigkeit: Immer, oft oder nur unter einer Bedingung?
• Auswirkung: Was können sie deshalb nicht tun?
• Kürzliche Änderung: Was hat sich direkt davor geändert?

Der letzte Punkt ist wichtiger, als viele Gründer erwarten. Ein neuer Deploy, eine DB-Änderung, eine Einstellung beim Auth-Provider oder KI-generierte Änderungen können still Dinge kaputtmachen.

Beispiel: „Auth: Bestehende Nutzer, die sich mit Google anmelden, werden in ~30% der Fälle zurück zu /login geleitet. Begann, nachdem wir gestern einen neuen Onboarding-Schritt hinzugefügt haben.“ Das ist eng genug für einen Entwickler, um zu handeln. Es ist auch die Art von Situation, bei der FixMyMess oft ansetzt, wenn ein KI-generiertes Prototypverhalten in Produktion anders ist.

Abschnitt 1: Aktuelles Verhalten (was jetzt passiert)

Dieser Abschnitt ist die Aufzeichnung dessen, was Sie heute beobachten können. Entwickler:innen nutzen ihn, um den Fehler zu reproduzieren, zu bestätigen, dass sie dasselbe sehen wie Sie, und zu vermeiden, das falsche Problem zu „fixen".

Geben Sie den Kontext genau an: wo es passiert, bei wem und in welchem Flow. Seien Sie spezifisch über den Screen, den Button, den Nutzertyp und ob es in Produktion, Staging oder nur lokal passiert.

Nutzen Sie diesen Ausfüllblock:

• Kontext: [Seite/Screen oder Feature], [Nutzertyp], [Umgebung], [Gerät/Browser]
• Auslöser: [Was der Nutzer genau macht, bevor es kaputtgeht]
• Schritte zur Reproduktion: [Schritt 1], [Schritt 2], [Schritt 3]
• Was Sie sehen: [Genaues Ergebnis], [genauer Fehltext], [was lädt/nicht lädt]
• Wie oft: [immer / manchmal], [ca. %], [seit wann]

Schreiben Sie das aktuelle Verhalten wie eine Videobeschreibung: „Ich klicke auf Log in, ich gebe E‑Mail/Passwort ein, ich drücke Submit, der Spinner läuft 10 Sekunden, dann erscheint ‚500: Internal Server Error‘.“ Ursachen kommen später. „Die API ist down“ ist meist eine Vermutung.

Fügen Sie Beweise in den Brief ein. Kopieren Sie den genauen Fehltext, notieren Sie Zeitstempel und IDs, die sichtbar sind (Nutzer‑E‑Mail, Bestellnummer, Request‑ID), ohne Secrets zu teilen.

Wenn es sich um KI-generierten Code handelt, nennen Sie kürzliche Prompt‑Änderungen, regenerierte Dateien oder große kopierte Blöcke. Solche Änderungen verändern oft Verhalten ohne, dass es jemand bemerkt.

Schlussendlich benennen Sie die Auswirkung klar und einfach. Blockiert es Signups, belastet es Support, belastet es das Werbebudget? Beispiel: „Neue Nutzer können keine Konten erstellen, Ads verbrennen Budget und Support erhält 20 Tickets/Tag.“ Wenn Sie ein Sicherheitsrisiko vermuten (offene Keys, SQL‑Injection, Auth‑Bypass), sagen Sie das direkt und markieren Sie es als dringend.

Wenn Sie eine schnelle Zweitmeinung brauchen, kann FixMyMess in einem kostenlosen Code-Audit bestätigen, was tatsächlich passiert — besonders wenn sich ein KI-generierter Prototyp in verschiedenen Umgebungen unterschiedlich verhält.

Abschnitt 2: Gewünschtes Verhalten (was stattdessen passieren soll)

Das gewünschte Verhalten ist der nützlichste Teil des Briefs, weil es „done“ definiert, ohne dem Entwickler zu sagen, wie er es umzusetzen hat.

Formulieren Sie es als Ergebnis, das jemand durch die Nutzung der App verifizieren kann. Wenn Sie keinen einfachen Test dafür vorstellen können, ist es wahrscheinlich eine Lösung, die als Anforderung getarnt ist.

Testbar machen (Ergebnisse beschreiben, keine Fixes)

Nutzen Sie klare, beobachtbare Aussagen, die mit einem Auslöser beginnen und mit einem Ergebnis enden. Beispiel: „Wenn ein Nutzer gültige Anmeldedaten eingibt und auf Log in tippt, landet er innerhalb von 3 Sekunden auf dem Dashboard und bleibt nach einem Refresh eingeloggt."

Ein einfaches Muster:

• Wenn [Nutzeraktion / Ereignis], sollte die App [sichtbares Ergebnis].
• Wenn [falsche Eingabe / Fehler], sollte die App [freundliche Fehlermeldung + was als Nächstes passiert].
• Das System sollte weiter funktionieren auch bei [häufige Einschränkung].
• Daten sollten gespeichert/aktualisiert werden, sodass [Nutzer den korrekten Zustand sieht].
• Erfolg sieht aus wie [eine messbare Prüfung].

Leitplanken und Erwartungen

Geben Sie auch Grenzen an. Sagen Sie, was nicht verändert werden darf, damit niemand das Problem „löst“, indem er einen für Sie wichtigen Workflow bricht.

Nennen Sie kniffelige Fälle, die Ihnen wichtig sind (häufig bei KI-generierten Apps): langsame Netze, ungültige Eingaben, leere Zustände, Session‑Verhalten nach Refresh/Leerlauf und Rollen/Berechtigungen. Sie brauchen nicht alle Edge‑Cases, nur die, die Probleme verursachen würden.

Wenn Sicherheit oder Compliance relevant sind, seien Sie explizit. Beispiele: „Keine Secrets im Client‑Code“, „Authentifizierung muss abgelaufene Tokens ablehnen“ oder „Fehlermeldungen dürfen nicht verraten, ob eine E‑Mail existiert.“ Wenn Sie ein kaputtes Prototyp übergeben, fangen Teams wie FixMyMess hier oft versteckte Risiken ab, bevor sie shipped werden.

Abschnitt 3: Priorität und Dringlichkeit (wie man entscheidet, was zuerst shipped)

Entwickler:innen arbeiten schneller, wenn sie wissen, was am wichtigsten ist. Priorität ist das Signal, das Wochen von „nice-to-have“-Arbeit verhindert, während das echte Feuer weiterbrennt.

Nutzen Sie eine einfache Skala und fügen Sie eine Ein-Zeilen-Begründung hinzu:

• P0 (muss jetzt behoben werden): Nutzer können eine Kernaktion nicht abschließen, Daten sind gefährdet oder es besteht wahrscheinliches Sicherheitsrisiko.
• P1 (als Nächstes): Die App funktioniert, hat aber erhebliche Reibung, einen großen Workaround oder Zuverlässigkeitsprobleme.
• P2 (später): Feinschliff, Edge‑Cases, kleine UX‑Probleme oder Verbesserungen, die reale Nutzung nicht blockieren.

Priorität ist nicht dasselbe wie Severity. Behandeln Sie es als zwei Fragen:

Severity ist, wie viel Schaden entsteht, wenn es kaputt bleibt (Geldverlust, Nutzer gesperrt, Sicherheitslücke). Dringlichkeit ist, wie schnell dieser Schaden relevant wird (Demo morgen, Vertragsfrist, andauernder Ausfall).

Beispiel: Ein Bug, der API‑Keys leakt, ist hohe Severity, auch wenn „noch niemand es bemerkt hat“. Ein kleiner visueller Fehler ist niedrige Severity, selbst wenn er bei einer Demo stört.

Fügen Sie Deadlines nur hinzu, wenn sie real und konkret sind. „ASAP“ ist keine Deadline. „Investor‑Demo am Freitag um 14 Uhr“ ist eine.

Wenn Sie mehrere Items sortieren, schreiben Sie die Regel so, dass niemand raten muss. Eine gängige Reihenfolge: Login/Signup/Checkout zuerst freischalten, Security/Secrets vor Featurearbeit fixen, Datenkorruption vor Performance‑Tuning, dann UI‑Politur.

Bei übernommenem KI‑Code ändern sich Prioritäten oft nach einer schnellen Diagnose. Wenn Sie unsicher sind, kann ein kurzes Audit (wie von FixMyMess angeboten) bestätigen, was wirklich P0 ist gegenüber dem, was nur bedrohlich aussieht.

Abschnitt 4: Acceptance Checks (wie wir wissen, dass es behoben ist)

Acceptance Checks verhindern „auf meinem Rechner funktioniert’s“. Sie verwandeln Ihr Ziel in einfache Tests, die jede:r ausführen und mit Ja/Nein beantworten kann.

Formulieren Sie jede Prüfung als eine einzelne Aussage, nicht als Diskussion. Wenn eine Entwicklerin nicht sagen kann, ob sie bestanden ist, ist es noch kein Check. Fünf bis zehn Checks sind üblich, aber fangen Sie klein an und behalten Sie nur, was zählt.

Beispiele zum Kopieren/Anpassen:

• Wenn ich eine gültige E‑Mail und das richtige Passwort eingebe, bin ich eingeloggt und lande auf dem Dashboard.
• Bei gültiger E‑Mail und falschem Passwort wird der Login geblockt und ich sehe die Meldung: „E‑Mail oder Passwort ist falsch.“
• Nach 6 falschen Passworteingaben in Folge wird der nächste Versuch für 10 Minuten gesperrt.
• Nach erfolgreichem Login wird eine Session erstellt, die nach 7 Tagen Inaktivität abläuft.
• Passwörter werden nie im Klartext gespeichert, und keine Secrets (API‑Keys, Tokens) tauchen im Client‑Code oder in Logs auf.

Fügen Sie mindestens einen Negativtest ein (was blockiert werden muss). Hier zeigen sich Sicherheits- und Missbrauchsprobleme: falsche Passwörter, ungültige Tokens, abgelaufene Links oder Zugriff auf Seiten ohne Anmeldung.

Seien Sie eindeutig bei Daten‑Erwartungen: was gespeichert wird, was aktualisiert wird und was privat bleiben muss. Wenn es eine Source of Truth gibt (DB vs Drittanbieter), sagen Sie das.

Fügen Sie Performance‑ oder Zuverlässigkeitschecks nur dann hinzu, wenn sie Teil des Problems sind. Wenn Sie unsicher sind, lassen Sie sie weg, bis Sie Belege haben.

Wenn Sie Hilfe brauchen, chaotisches Verhalten in präzise Acceptance‑Checks zu übersetzen, kann FixMyMess das in einem kostenlosen Code‑Audit tun, damit Entwickler:innen ohne Raten arbeiten können.

Schritt-für-Schritt: So schreiben Sie den Brief in 20 Minuten

Öffnen Sie ein frisches Doc und geben Sie ihm einen Titel mit einem Satz: was ist kaputt und für wen (z. B. „Login schlägt fehl für neue Nutzer in Staging“). Das hält den Brief fokussiert und verhindert, dass er zur Wunschliste wird.

0–20 Minuten Workflow

Folgen Sie dieser Reihenfolge und hören Sie auf, sobald jeder Punkt klar beantwortet ist:

1. (3 Min) Wählen Sie einen Pfad zum Fix. Schreiben Sie die genaue Nutzerreise (z. B. „Sign up -> verify email -> log in“). Bei mehreren Problemen: separater Brief pro Problem.
2. (5 Min) Erfassen Sie Repro‑Schritte. Nummerierte Schritte, die eine nicht‑technische Person ausführen kann, beginnend mit einem sauberen Zustand (ausgeloggt, neuer Tab). Was Sie klicken und was Sie tippen.
3. (4 Min) Fügen Sie sichere Beispiel‑Inputs hinzu. Test‑E‑Mails, Beispiel‑IDs, Beispieltexte, Rollen (Admin vs Member) zum Kopieren/Einfügen.
4. (4 Min) Geben Sie die Umgebung an. Wo passiert es: Staging, Produktion oder beides? Feature‑Flags, Region, Gerät/Browser, echte Provider vs Sandbox erwähnen.
5. (4 Min) Definieren Sie den „Done“-Check. 2–3 Acceptance Checks, die jede:r ohne Spezialtools verifizieren kann.

Wenn Sie Logging oder Analytics beschreiben, schreiben Sie, was Sie von außen prüfen können. „Ich sollte innerhalb von 60 Sekunden eine Reset‑E‑Mail erhalten“ ist besser als „Prüfe den Auth‑Worker‑Log“. Wenn Sie Zugriff haben, halten Sie es einfach:

• Was zu prüfen ist: ein Event‑Name oder genaue Fehlermeldung (kopieren Sie den Text)
• Wo es erscheint: Browser‑Konsole, App‑Banner, E‑Mail‑Postfach oder ein Dashboard‑Screenshot
• Erfolgs-Signal: der genaue Screen, Redirect oder die Bestätigungsmeldung

Wenn die App von einem KI‑Tool generiert wurde (Lovable, Bolt, v0, Cursor, Replit), nennen Sie das. Es hilft Entwickler:innen, typische Schwachstellen wie Auth‑Wiring, fehlende Env‑Variablen, fragile Routen und offengelegte Secrets vorauszusehen.

Häufige Fehler, die Entwickler:innen aufhalten

Die meisten Verzögerungen entstehen durch Briefs, die das Problem hinter Meinungen, fehlenden Details oder einem Sammelsurium von Problemen verstecken.

Eine übliche Falle ist, die Lösung vorzuschreiben statt das gewünschte Verhalten zu nennen. „Move auth to Redis“ oder „rewrite it in Next.js“ mag richtig sein, aber es überspringt den Kern: was fehlt und was „behoben“ heißt. Konzentrieren Sie sich auf Verhalten und Checks, und lassen Sie die Entwickler:innen den sichersten Weg wählen.

Vage Acceptance‑Checks verlangsamen ebenfalls. Wörter wie „funktioniert“, „stabil“ oder „sieht gut aus“ lassen Interpretationsspielraum. Wenn Sie es nicht in einer einfachen, reproduzierbaren Weise testen können, kann niemand sicher shippen.

Viele Probleme in einem Brief bündeln erzeugt Churn. Ein kaputtes Login, langsame Seite und Webhook‑Bug sind separate Geschichten mit unterschiedlichen Risiken und Ownern. Gemischt werden Schätzungen unklar und nichts fertig.

Das Auslassen von Repro‑Schritten ist teurer, als es scheint. Wenn ein Entwickler nicht schnell reproduzieren kann, verbringt er Zeit mit Accounts, Environment‑Setup und Rückfragen.

Schnelle Checkpunkte vor dem Versand des Dokuments:

• Es beschreibt nicht, wie man es baut, sondern wie Erfolg aussieht.
• „Acceptance“ ist kein Gefühl, sondern ein prüfbarer Check.
• Nicht mehr als ein nutzerrelevantes Problem pro Brief.
• Repro‑Schritte, Testkonto oder Beispieldaten sind vorhanden.
• Schlüsselkontext ist angegeben (Gerät, Browser, Nutzerrolle, Umgebung).

Bei übernommenem KI‑Code (Lovable, Bolt, v0, Cursor, Replit) tauchen diese Fehler häufiger auf, weil die App bis echte Nutzer‑Edge‑Cases oft gut aussieht. Wenn Ihr Team feststeckt, kann FixMyMess mit einem schnellen Audit vage Probleme in klar uitvoerbare Aufgaben verwandeln.

Quick‑Checklist bevor Sie den Brief abschicken

Ein guter Handoff ist ohne Meeting leicht umsetzbar. Lesen Sie Ihren Brief einmal so, als wären Sie die Entwicklerin, und prüfen Sie:

• Können Sie das Problem in einem Satz zusammenfassen, der Nutzer und Fehler nennt (z. B. „Neue Nutzer können sich auf Mobile nicht mit Google anmelden“)?
• Ermöglichen die Repro‑Schritte das Nachstellen in unter 2 Minuten (Startpunkt, Klicks, Inputs, sichtbares Ergebnis)?
• Ist das gewünschte Verhalten als Nutzererlebnis formuliert, sodass ein Tester ohne Raten Ja/Nein sagen kann?
• Ist die Priorität eindeutig (P0/P1/P2 oder „heute/diese Woche/nächste“), mit Grund (Umsatz‑Risiko, Sicherheit, Onboarding‑Drop, Support‑Volumen)?
• Sind Acceptance‑Checks konkret (was muss passieren, was darf nicht passieren, und welche Daten bzw. welcher Screen bestätigt es)?

Suchen Sie auch nach versteckten „Unknowns“, die Arbeit verlangsamen. „Login ist kaputt“ reicht nicht, aber „Login schlägt nur für Konten fehl, die vor dem Deploy am Montag erstellt wurden“ ist ein starkes Indiz. Nennen Sie die Umgebung (Produktion vs Staging) und ob es neu oder langfristig ist.

Für KI‑generierte Apps fügen Sie eine Zeile hinzu, welches Tool den Code erzeugt hat (Lovable, Bolt, v0, Cursor, Replit) und ob Secrets offengelegt sein könnten. Das ändert oft die ersten Debug‑Stunden erheblich. Wenn Sie unsicher sind, können Teams wie FixMyMess ein schnelles Audit durchführen, um Unklarheiten in klare, testbare Aufgaben zu verwandeln.

Beispiel: Ein ausgefüllter Remediation‑Brief für ein kaputtes Login

Kopieren Sie das hier und passen Sie Details an. Es ist so formuliert, dass ein Entwickler ohne Raten handeln kann.

Title: Signup schlägt fehl nach jüngsten KI-generierten Auth‑Änderungen

Aktuelles Verhalten (was jetzt passiert): Neue Nutzer können sich nicht registrieren. Nach Absenden des Signup‑Formulars sehen sie „500: Internal Server Error“ und die App bleibt auf derselben Seite.

In den Server‑Logs wirft das Backend: „JWT_SECRET is undefined“. Das begann, nachdem wir KI-generierten Auth‑Code aus einem Prototyp gemerged haben. Bestehende Nutzer, die bereits eingeloggt sind, können zwar browsen, werden aber gelegentlich ausgeloggt.

Gewünschtes Verhalten (was stattdessen passieren soll): Ein neuer Nutzer kann die Registrierung abschließen, erhält eine Session und landet auf dem Dashboard. Bestehende Nutzer bleiben wie erwartet eingeloggt.

Secrets dürfen nie an den Browser gesendet werden, und Auth‑Endpoints müssen grundlegenden Missbrauch abfangen (keine unbegrenzten, schnellen Registrierungsversuche).

Priorität und Dringlichkeit: P0 (blockiert Umsatz). Signup ist der Haupteinstiegspunkt für Trials und derzeit für alle neuen Nutzer kaputt.

Acceptance Checks (wie wir wissen, dass es behoben ist):

• Signup gelingt für einen brandneuen Nutzer (E‑Mail + Passwort) in Produktion.
• Login klappt für einen bestehenden Nutzer und die Session bleibt nach einem Refresh bestehen.
• Keine Secrets sind im Client‑Code, in Antworten oder im Build‑Output sichtbar (z. B. bleibt JWT_SECRET serverseitig).
• Grundlegendes Rate‑Limiting oder Throttling existiert für Signup/Login (ausreichend, um offensichtliche Bursts zu stoppen).
• Fehler zeigen eine nutzerfreundliche Meldung, und die Server‑Logs enthalten die realen Fehldetails.

Notizen / Anhänge:

• Genaue Fehlermeldung aus UI und Server‑Log (kopieren/einfügen).
• Umgebung, in der es passiert (prod/staging/local) und Zeitpunkt, wann es begann.
• Betroffener Nutzertyp: „nur neue Nutzer“ und ggf. spezifische Browser/Geräte.
• Relevante Commits oder KI‑Tool‑Änderungen im Bereich Auth.

Wenn dieses Problem aus einer KI‑generierten Codebasis stammt, übergeben Teams es oft an einen Dienst wie FixMyMess zur gezielten Diagnose und Reparatur und validieren das Ergebnis gegen die Acceptance‑Checks oben.

Nächste Schritte: Handoff, Follow‑through und wann Sie Hilfe holen sollten

Ein Brief funktioniert nur, wenn der Handoff sauber bleibt: Entwickler:innen wissen, was zu liefern ist, Sie wissen, wie zu prüfen ist, und alle wissen, wer Fragen beantwortet.

Vereinbaren Sie zwei Owner: eine Person, die den Fix ausliefert, und eine Person (oft Sie), die Produktentscheidungen schnell bestätigen kann. Setzen Sie einen Zeitplan, der Test und Review einschließt, nicht nur Coding.

Ein einfacher Handoff‑Flow:

• Weisen Sie eine:n Engineering‑Owner und eine:n Entscheider:in für Produktfragen zu.
• Setzen Sie ein Ship‑Datum und eine Check‑in‑Zeit (auch 15 Minuten reichen).
• Bestimmen Sie, wo Updates gepostet werden (ein Thread, ein Doc).
• Legen Sie die Acceptance‑Checks als Definition of Done fest.
• Entscheiden Sie, wer Scope‑Änderungen genehmigen darf.

Scope Creep passiert. Wichtig ist, wie Sie damit umgehen. Wenn der Fix ein zweites Problem aufdeckt, entscheiden Sie, ob es einen neuen Brief braucht (besser, wenn separat) oder ein Addendum (wenn es nötig ist, um die ursprünglichen Acceptance‑Checks zu erfüllen). Halten Sie die Entscheidung schriftlich, damit Entwickler:innen nicht mitten im Fix verhandeln müssen.

Wenn Ihre App von Tools wie Lovable, Bolt, v0, Cursor oder Replit generiert oder stark bearbeitet wurde, erwarten Sie versteckte Kopplungen. Eine „kleine“ Login‑Änderung kann Routing, Session‑Storage, API‑Aufrufe oder DB‑Regeln brechen, weil Teile zusammengesetzt wurden ohne klare Grenzen.

Holen Sie Hilfe, wenn der Bug Auth, Zahlungen oder Nutzerdaten berührt; Sie offengelegte Secrets oder seltsame Berechtigungen sehen; ein Fix immer wieder andere Dinge kaputtmacht; niemand das Verhalten sicher erklären kann; oder Sie schnell eine produktionsreife Lösung brauchen.

Wenn Sie eine zweite Meinung wollen, spezialisiert sich FixMyMess auf die Diagnose und Reparatur von KI‑generierten Apps, inklusive Logikfixes, Security‑Härten, Refactoring und Deployment‑Vorbereitung — beginnend mit einem kostenlosen Code‑Audit.