Debugging Checkliste für Gründer:die 5-Minuten-Reihenfolge

Eine Debugging Checkliste: Wenn etwas kaputtgeht, prüfe in genau dieser Reihenfolge: Seite neu laden, die Konsole lesen, bestätigen, dass du eingeloggt bist, bestätigen, dass die App wirklich läuft, bestätigen, dass du deine Änderungen gespeichert hast. Diese fünf Prüfungen dauern fünf Minuten und lösen 90 % der Probleme. Die Reihenfolge ist die Methode – die meisten Gründer debuggen durch zufälliges Raten, weshalb sie festhängen.

Debugging ist eine Fähigkeit, keine Magie. Hier die vollständige Checkliste, vom Fünf-Minuten-Schnellcheck bis zur Brechstange.

Debugging Checkliste, Schritt 1: der 5-Minuten-Schnellcheck (90 % der Probleme)

1. Lade die Seite neu. Das löscht temporäre Zustände und lädt deine Daten neu. Hilft ein einfaches Neuladen nicht, mach einen Hard Refresh – halte beim Neuladen die Umschalttaste gedrückt –, der auch die zwischengespeicherten Dateien leert, aus denen dein Browser vielleicht noch von letzter Woche liefert.
2. Öffne die Konsole und suche nach Rot. In der Entwicklerkonsole des Browsers melden sich Fehler. Roter Text ist ein Fehler, und die Meldung nennt meist Datei und Zeile. Wenn sie wie Hieroglyphen aussieht, entschlüsselt wie man Fehlermeldungen liest die Muster.
3. Bist du eingeloggt? Die meisten Funktionen erfordern Authentifizierung, und Sitzungen laufen leise ab. Suche deine Nutzerinfo im Header; im Zweifel melde dich ab und wieder an. Ein erstaunlicher Anteil „kaputter“ Funktionen ist nur ein abgelaufener Login.
4. Läuft die App überhaupt? Wenn du lokal arbeitest, schau ins Terminal – dein Entwicklungsserver sollte Logs ausgeben. Ist er abgestürzt oder nie gestartet worden, funktioniert nichts, und kein noch so langes Code-Anstarren wird das beheben.
5. Hast du die Datei gespeichert? Ungespeicherte Änderungen laufen nicht. Achte auf den Punkt neben dem Dateinamen in deinem Editor. Ja, das passiert jedem.

Die meisten Bugs sind so einfach: nicht eingeloggt, Speichern vergessen, Server läuft nicht, Tippfehler, Neuladen vergessen. Beginne zuerst mit dem Einfachen – das ist nicht unter deiner Würde, das ist Statistik.

Der 15-Minuten-Tiefencheck

Wenn der Schnellcheck es nicht gefunden hat, geh eine Ebene tiefer – weiter der Reihe nach, weiter eine Sache zur Zeit:

• Leere den Browser-Cache. Alte zwischengespeicherte Dateien können mit neuem Code kollidieren. Meist reicht ein Hard Refresh.
• Öffne den Network-Tab. In denselben Entwicklertools zeigt der Network-Tab jede Anfrage, die deine App stellt. Lade die Seite neu, suche rote Zeilen – fehlgeschlagene Anfragen – und lies ihre Statuscodes (Tabelle unten).
• Wurden deine Datenbankänderungen tatsächlich angewendet? Wenn du kürzlich die Datenbankstruktur geändert hast, bestätige, dass die Änderung gelaufen ist – eine fehlende Tabelle oder Spalte bricht alles, was sie berührt. Prüfe in deinem Datenbank-Dashboard, ob die erwartete Tabelle da ist.
• Prüfe deine Einstellungsdatei. Apps lesen Geheimnisse und Adressen aus einer Umgebungsdatei. Fehlende Werte, ein falscher Schlüssel oder zusätzliche Leerzeichen brechen alles – und nach einer Änderung musst du die App neu starten, damit sie es bemerkt.
• Verdächtige deine letzte Änderung. Wenn es vor einer Stunde noch lief, ist alles, was du seitdem geändert hast, der Hauptverdächtige. Mach die neueste Änderung vorübergehend rückgängig oder kommentiere sie aus und sieh, ob das Problem verschwindet.

Was dir der Network-Tab sagt

Diese vier Zeilen machen den gruseligsten Tab im Browser zur Triage-Schwester: Sie sagen dir, ob das Problem deine Sitzung, deine Adresse oder dein Code ist.

Das BuchThe Solopreneur RevolutionLuis Gonçalves darüber, wie du neben dem Job mit KI ein Solopreneur-Business aufbaust.Zum Buch →

Die Brechstange

Wenn nichts anderes hilft, gibt es die Entwicklerversion von „aus- und wieder einschalten“: die App stoppen, die installierten Abhängigkeiten löschen, sie frisch neu installieren, den Browser-Cache leeren und neu starten. Das klingt grob, behebt aber zuverlässig beschädigte Installationen, veraltete Abhängigkeiten und die zermürbende Kategorie „bei meinem Freund läuft es, bei mir nicht“.

Nutze sie zuletzt, nicht zuerst – denn sie behebt Dinge, ohne dir zu sagen, was falsch war, und beim nächsten Mal steckst du genauso fest.

Die drei Regeln, mit denen die Checkliste funktioniert

Ändere eine Sache zur Zeit. Wenn du fünf Dinge änderst und es läuft, weißt du nicht, was es repariert hat – und damit auch nicht, was es kaputtgemacht hat.

Teste nach jeder Änderung. Staple keine Fixes. Änderung machen, prüfen, weitergehen.

Dokumentiere, was funktioniert hat. Dieselben Bugs kehren wieder. Eine Notizdatei mit „Symptom → Lösung“ wird binnen eines Monats dein schnellstes Debugging-Werkzeug.

Und wenn die Checkliste ausläuft: eskaliere bewusst, nicht verzweifelt. Gib den Fehler mit den KI-Debugging-Prompts an deinen KI-Assistenten weiter oder schreibe einen ordentlichen Bug-Report mit wie man um technische Hilfe bittet. Bis dahin kannst du beantworten, was du getan hast, was du erwartet hast, was passiert ist und was du versucht hast – genau das, was die Checkliste dich gerade hat sammeln lassen.

12 WochenDeine Konzernkarriere war nie der PlanBewirb dich beim Solopreneur Accelerator.Jetzt bewerben →

Häufig gestellte Fragen

Was sollte ich zuerst prüfen, wenn meine App kaputtgeht?

Lade die Seite neu, dann lies die Konsole. Diese beiden Schritte dauern unter einer Minute und lösen einen großen Teil der Probleme von selbst. Dann bestätige, dass du eingeloggt bist, die App läuft und deine Änderungen gespeichert sind. Erst nach diesen fünf solltest du anfangen, Code zu lesen.

Warum ist Debuggen in fester Reihenfolge wichtig?

Weil zufälliges Raten mehrere Dinge gleichzeitig ändert, sodass du nie erfährst, was tatsächlich falsch war. Eine feste Reihenfolge testet zuerst die wahrscheinlichsten, am billigsten zu prüfenden Ursachen und schließt sie nacheinander aus – im Schnitt schneller und als Bonus lehrt sie dich die Fehlermuster deines Systems.

Meine Änderungen erscheinen nicht – was ist los?

In der Reihenfolge der Wahrscheinlichkeit: Du hast die Datei nicht gespeichert, die App läuft nicht, dein Browser zeigt eine zwischengespeicherte Version (Hard Refresh) oder du bearbeitest eine andere Datei als die, die die App nutzt. Alle vier sind Zwei-Minuten-Prüfungen, und zusammen decken sie fast jeden Fall ab.

Wann sollte ich aufhören zu debuggen und um Hilfe bitten?

Nach dem Schnellcheck und dem Tiefencheck – etwa 20 Minuten systematischer Arbeit. Bis dahin kannst du sagen, was du getan hast, was du erwartet hast, was passiert ist, den genauen Fehler und was du versucht hast. Das ist alles, was eine gute Hilfeanfrage braucht, ob du eine KI oder einen Menschen fragst.