I Changed One Thing and Now My App Is Broken. How Do I Fix It?
Everything was working. You made one small change — updated a line, tweaked a setting, added a feature — and now something that worked perfectly before does not work at all. You have no idea what you broke or how to get back to the version that worked. If you have ever stared at a broken app wondering whether to cry or start over, this is the post you need.
The reassuring truth: this happens to everyone, including experienced developers. Something specific caused this. You can find it. Here is how to debug your code and get back to working.
First: Do Not Delete Everything
The instinct when something breaks badly is to start over. Resist it. Starting over throws away everything that was working along with what broke. Almost every broken app is recoverable — it just needs a diagnosis first.
Before you do anything else, answer this question honestly: do you remember what you changed?
If yes — that change is almost certainly the cause. Start there.
If no — or if you made several changes and cannot remember which one caused the problem — you need a way to see what changed. That is where GitHub history becomes invaluable.
If Your Code Is on GitHub: Revert to What Worked
Go to your repository on GitHub. Click the Commits tab. You will see every saved version of your project with timestamps and your commit messages.
Find the last commit where everything worked. Click on it to see exactly what was different between that version and now — GitHub shows you a line by line comparison of what changed.
To go back to that version completely without using the terminal:
- Click the Browse files button on that commit
- Download the repository as a ZIP file from that point in history
- Replace your current files with the ones from the ZIP
- Test that it works, then commit the restored version to GitHub immediately
This is the single best argument for saving to GitHub regularly. The ability to travel back to any working version is worth more than any other feature it offers.
If Your Code Is Not on GitHub: Use Undo
Your text editor keeps an undo history even after you close and reopen files. In VS Code, press Ctrl+Z on Windows or Command+Z on Mac and keep going. Work backwards until the app works again, then stop immediately and save that version to GitHub so you have it safely backed up.
If undo does not reach far enough back, paste the broken file into your AI and say: "This code is broken after a recent change. Can you identify anything that looks wrong, incomplete, or inconsistent?" It can often spot the problem faster than you can by reading through it manually.
How to Debug When You Cannot Pinpoint the Change
If you made several changes and cannot isolate which one caused the problem, work through this sequence:
Read the error message first. If your app is throwing an error, paste the entire error message into your AI before doing anything else. Error messages point directly to the problem most of the time — the last line tells you what went wrong, the line above it tells you where. This alone solves the majority of broken app situations.
Undo changes one at a time. If there is no error message, undo your most recent change and test. If it still breaks, undo the next one. Keep going until it works. The change that fixes it is the one that caused the problem. Never undo multiple things simultaneously — you need to know exactly which change made the difference.
Ask your AI with full context. Do not just say "my app is broken." Give it everything: what you changed, what the app was doing before, and the full error message if there is one. Try: "My app was working before I made this change: [describe it]. Now I am getting this error: [paste it]. What went wrong and how do I fix it?"
When You Have Been Going in Circles
If you have tried everything above and are still stuck, take a completely different approach.
Paste your entire broken file — or the most relevant part of it — into your AI and say: "This code is broken and I cannot figure out why. Here is the full code. Please identify what is wrong and give me a corrected version."
If your file is very long and the AI struggles with it, paste just the section around the error, or ask: "Which part of this code should I focus on to debug this error?"
This is not giving up. This is using the right tool for the job. An AI can read your entire file at once and spot inconsistencies that would take a human hours to find.
The One Thing to Remember
A broken app after a change is a debugging problem, not a disaster. The fix is almost always in the error message, the undo history, or the GitHub commit log. The worst thing you can do is delete everything and start over. The best thing you can do is read the error, isolate what changed, and ask your AI with specific context.
Want your app running reliably without the trial and error? → Snapdock
New here? This might help: Python errors. What your computer is actually trying to tell you. →