Common wall · My app was working and now it is broken
The app worked yesterday. Today it doesn’t.
A plain-English recovery path for an AI-built app that regressed after a change, including what evidence to preserve and when to call for Rescue.
Rescue signal
Reviewed July 13, 2026
Direct answer
What this wall usually means.
When a previously working app breaks, first treat the failure as a regression: something changed in the app, its data, a connected service, or the live settings. Do not rewrite the feature. Preserve today’s state, identify the last known-good release, compare the smallest relevant change, and verify the customer journey step by step.
Recognize it
Symptoms that belong together.
- A feature failed after work in a seemingly unrelated screen.
- The preview and the live app now fail in different ways.
- Rolling forward with another AI fix creates a new error.
- The project history contains a working state, but you are afraid to restore it.
First checks
Gather evidence before another patch.
- 01Record the exact time and action where the failure appears.
- 02Save the current state before attempting a rollback or generated change.
- 03Locate the last release where the complete journey worked—not just the screen.
- 04Check whether an outside service or live setting changed at the same time.
DIY or bring in help?
Stop when the risk is larger than the clue.
A focused check is reasonable when you have a stable version and one repeatable failure. Bring in help when the app, customer impact, or safety boundary is no longer clear.
- Real customers are affected or data may have changed incorrectly.
- You cannot compare or restore versions without risking newer work.
- The regression crosses multiple features and the source is no longer obvious.
- Book a Rescue call →
Inside the Ship Framework
Stabilize + Watch
Stabilize establishes the last known-good state and a repeatable regression. Watch adds enough visibility to tell whether the same failure returns after recovery, instead of waiting for a customer to report it.
See all seven stages →Questions founders ask
Before you change anything.
Why did an unrelated AI change break my app?
Features often share data, state, permissions, or reusable building blocks that are not visible on the screen. A change can appear local while altering something several customer journeys depend on.
Is rolling back always the right first move?
Not always. Preserve the current state first and understand whether customer data or an outside service also changed. A code rollback may restore behavior, but it cannot automatically reverse every data or configuration change.
What should I bring to a Rescue call?
Bring the live link, the last time the journey worked, the exact steps that now fail, and any saved version names you recognize. Do not send passwords, private keys, or real customer records.
Related walls
Symptoms often travel together.
Published by ShipTheVibes. This guide is general product-readiness information, not legal or security incident advice.
Your next move
Turn the symptom into a useful next step.
Tell us what you built, what customers see, and when it last worked. The Audit helps determine whether Rescue is the right next move.