When an AI-built product keeps breaking, the next step is not necessarily another prompt or a complete rebuild. The priority is to stabilise the product, secure access to its code and data, and identify what is causing the failures before deciding how to recover it.
Software project rescue follows four steps: stabilise, assess, decide and recover. This approach helps you determine which issues can be fixed, whether parts of the product need rebuilding, or whether stopping the project makes more business sense. It also helps you understand when specialist support is needed and what to look for in a rescue partner.
TL;DR
Software project rescue is taking control of a failing software product, finding out what still works, and deciding whether to fix it, rebuild parts of it or stop.
- Data exposure, payment errors and outages need action before anything else: contain access, rotate exposed keys in a controlled way and check whether a personal data breach must be reported under GDPR Article 33.
- Specialist support is most valuable when failures recur without a clear cause, sensitive data or payments may be affected, a major rebuild decision needs evidence beyond the original team’s assumptions, or nobody in the company can read the code.
- Stopping is worth considering when the product no longer has a viable business case, the value it delivers does not justify the cost and risk of recovery, or a suitable alternative meets the business need more effectively.
How to rescue a failing AI-built project
The four steps below are a working framework, not a mandatory procedure: urgent containment can run alongside the assessment, and well-understood fixes can start before every finding is in. What matters is that no major decision, such as a rebuild, is taken before the assessment. The steps apply the logic of shipping AI-built products safely to a product that is already in trouble.
Step 1: Stabilise the product and secure access
Stabilising an AI-built product means limiting change until someone understands its current state. Pause non-essential features and uncontrolled changes, including AI-tool regeneration on the live version, while preserving the ability to deploy urgent security and reliability fixes. Assign a clear decision-maker for production changes, record the current state and make sure critical changes can be tested and reversed.
Then identify every critical account, confirm who controls it and secure company-authorised access. Prioritise these services:
- the code repository (for example GitHub or GitLab) and the AI builder workspace
- hosting and deployment services
- the database and authentication service (for example Supabase or Firebase)
- the domain and DNS
- payments (for example Stripe) and App Store or Google Play developer accounts
Document the accounts that require a formal transfer, then plan ownership changes and credential rotation without interrupting essential operations. A rotated key has to be updated in every system that uses it, and the service checked afterwards. Where a repository moves, GitHub’s documentation confirms that its issues, pull requests and wiki move with it. Take a database backup the company controls. If customer data may already be exposed, establish whether a personal data breach has occurred; the GDPR notification timeline runs from the moment the controller becomes aware of it.
Step 2: Assess what is broken and what still works
Assessing a failing product means separating what still works from what breaks before deciding anything. Start with the critical flows that earn money or hold personal data, such as sign-up, login, payment and admin screens, and record what fails, under which conditions and since when. Then trace each failure to its cause in the code, data handling, configuration or deployment, rather than patching the symptom.
Access control comes first: broken access control is ranked first in the OWASP Top 10:2025. If users can access records belonging to other users, treat this as a potential security incident requiring prompt investigation and containment, rather than an ordinary application bug. The guide to an AI code audit sets out what a full assessment covers; for AI-built products, Sunbytes runs this as an AI-built product review.
Sort the findings into two groups: fix now (data exposure, payment errors, outages) and improve later (code structure, performance, maintainability).
Not sure whether your product needs a rescue or a few fixes? An AI-built product review reviews software engineering and security together and shows what to fix now and what can wait. Discuss your AI-built product review →
Step 3: Decide whether to fix, rebuild or stop
Deciding later means the decision follows from the assessment, not from how frustrating the product has become:
- Fix in place when the core business logic produces correct results and the failures cluster in a few areas, such as login, permissions or payments.
- Rebuild the failing parts when the data model or architecture is wrong in specific areas, while the rest keeps running. The refactor or rewrite decision covers the signals; product engineering covers a phased rebuild.
- Consider stopping when the product no longer has a viable business case, the value it delivers does not justify the cost and risk of recovery, or a suitable alternative meets the business need more effectively. Assess customer commitments, data obligations and the cost of shutting down before making the decision.
If the decision is to stop, the shutdown still takes work: tell users the shutdown date, export the data they ask for, stop keeping personal data that is no longer needed (GDPR Article 5(1)(e)), handle erasure requests under Article 17, revoke API keys and cancel paid services.
Step 4: Recover safely and establish ownership
Recovery means releasing fixes in small steps, each with monitoring and, where the change allows it, a rollback path. Not every change is easy to reverse: database migrations and data corrections need a backup and a test run before they go live. Set one rule for the AI coding tool: its changes go to a separate branch and a person reviews them before release. Then name the person or team that owns the product after the rescue; maintaining an AI-built app covers what that ownership involves.
Can your AI-built product still be saved?
An AI-built product can be saved when its core business logic produces correct results and the failures sit in identifiable areas such as login, data access, payments or deployment. When the business logic itself is wrong, fixing code will not make the product work; the business model needs a redesign or new validation before any recovery decision. Table 1 helps diagnose the technical symptoms; Table 2 supports the business-level decision.
| Symptom | Possible cause | Immediate action |
|---|---|---|
| Every fix breaks another feature | No automated tests to show what a change broke | Pause non-essential changes; list the broken flows |
| Works in preview, fails in production | Missing environment variables, build settings or hosting configuration | Compare the preview and production configuration |
| Users can see other users’ data | Missing permission checks or database access rules | Contain access and investigate as a potential security incident |
| Login or payments behave inconsistently | Session logic errors; for payments, one possible cause is events processed without signature verification | Test both flows end to end and check how payment events are verified |
| Costs rise without new features | Repeated regeneration or unlimited calls to AI model APIs | Set spending limits and review usage logs |
| Nobody can explain a core flow | No documentation; original builder unavailable | Get repository access and the list of known bugs first |
| Security warnings or exposed keys | Secrets placed in front-end code | Move secrets server-side and rotate the keys in a planned way |
Platform documentation describes two of these causes. Supabase’s documentation states that “a table in an exposed schema without RLS is readable and writable by any role with a grant on it”, so the row-level security setting of each exposed table belongs in the assessment. Stripe’s documentation warns that without signature verification “an attacker could send fake webhook events to your endpoint”, which makes unverified webhooks one cause to rule out when payments misbehave. Exposed keys are covered in leaked API keys in AI products.
More prompting can make these symptoms worse when no tests show what a change broke: each prompt fixes the symptom described, and a regenerated file can undo an earlier fix. In a 2023 user study by Perry et al., participants who used an AI assistant on the study’s security tasks wrote significantly less secure code and were more likely to believe their code was secure. The study measured code written in controlled tasks, not the security of AI-built products on the market, but it supports having a person review AI-generated fixes before release.
| Situation | Verdict | Next step |
|---|---|---|
| The business case holds, failures are isolated, no data or payment risk | Continue | Fix the issues and review the code before the next release |
| The business case holds, but failures recur or data or payments are at risk | Rescue | Contain urgent issues, then stabilise and assess |
| No viable business case, recovery cost and risk exceed the value, or a suitable alternative meets the need more effectively | Consider stopping | Check customer commitments, data obligations and the cost of shutting down |
Who should rescue your software project?
The original developer can investigate and fix well-understood issues, particularly when they know the system and remain accountable for the work. An independent assessment becomes more valuable when failures recur without a clear cause, sensitive data or payments may be affected, or a major rebuild decision needs evidence beyond the original team’s assumptions.
| Option | Works when | Watch out for |
|---|---|---|
| Original developer | Issues are well understood, the developer knows the system and stays accountable, and the company has secure access to every critical account | Recurring failures without a clear cause need a second view |
| External reviewer | You need an assessment you can rely on before a major decision | The assessment alone fixes nothing; the fixes need a team |
| Rescue team | You want the assessment and the fixes from one party | Agree on written findings before any fix starts |
| Internal team | You have, or will hire, developers who will own the product long term | The team needs the assessment and secure account access first |
Red flags when choosing a rescue partner:
- a full rebuild proposed before anyone has read the code
- a fixed scope or price before any assessment
- accounts kept in the partner’s name instead of the company’s
- no written findings or evidence behind the recommendations
- a promise that the AI tool will fix everything faster
- findings that cannot be explained in plain language
What determines the scope and cost of a rescue?
The scope of a rescue depends on the product’s size and complexity, how many users depend on it and the state of its code. Size alone does not decide it: a small app with exposed customer data can need more urgent work than a larger app with sound access rules. Four groups of factors decide the effort:
- Access and ownership: accounts and credentials that are missing or held by someone else
- Risk: whether customer data or payments are affected, and how many live users depend on the product
- Technical state: the size of the codebase, its integrations, and whether tests and documentation exist
- The decision: whether the assessment leads to fixing, rebuilding or stopping
Because each of these factors differs per product, Sunbytes scopes every rescue case by case; talk to us about a review for advice on yours.
How Sunbytes helps with AI-built product rescue
An app rescue only pays off when the assessment after stabilisation is clear enough to decide on. Sunbytes’ AI-built product review is built for that step. It reviews the code, architecture, security, reliability and deployment behind an AI-built product, with software engineering and security reviewed together, including authentication, permissions, cross-user access, exposed secrets and database rules.
The review produces clear findings with evidence, a prioritised action plan that separates what to fix now from what can wait, and a technical handoff that your team or your AI coding tool can act on. Your team can make the fixes, or Sunbytes fixes the priority issues and checks them again. When parts of the product need re-engineering, product engineering starts with a Product Blueprint and continues through Rebuild, Run and Evolve, keeping the existing product running where possible.
The work is Netherlands-led, delivered with engineering capacity in Vietnam and handled under ISO 27001-certified security management, backed by 15+ years in software delivery and 300+ projects. If your product keeps breaking, talk to us about a review and decide your next step on evidence.
