Software Project Rescue: How to Take Over a Failing or AI-Built Project

Projects fail for familiar reasons: a vendor disappears, a freelancer leaves, deadlines slip for months or a prototype built quickly with AI tools turns into a product that real customers now depend on. The owner is left with code nobody fully understands, credentials scattered across personal accounts and a growing list of bugs.

A software project rescue succeeds when the new team secures access first, audits before it builds and decides between repairing and rebuilding based on evidence from the code, not on the first impression of it.

This article sets out a takeover playbook for the first 30 days, a rule for choosing between rescue and rebuild, the specific problems found in AI-built applications and what a rescue costs. It is not legal advice on disputes with a previous vendor, and it does not cover recovering lost data from failed hardware.

Key takeaways

• Secure access before anything else: source code, cloud accounts, domains, databases, app store accounts and third-party services.
• Audit before writing new code. A one- to three-week audit usually costs far less than a single wrong decision about rebuilding.
• Rescue is usually cheaper than a rebuild when the data model is sound, the main flows work and the problems are concentrated in a few areas.
• AI-built applications often share the same weaknesses: secrets in the code, missing server-side permission checks and no automated tests.
• In Veracode's 2025 tests, AI-generated code contained security flaws in 45% of cases.
• Stabilize before adding features: automated tests on critical paths, working CI, monitoring and backups.

Signs a project needs rescue

• Releases have stopped or keep breaking things. Every deployment creates new bugs, so the team deploys less and less.
• Estimates have lost meaning. Small features take weeks, and nobody can explain why.
• The original team is gone or unresponsive. The vendor has stopped replying, or the only developer who knows the system has left.
• Nobody owns the accounts. Code, hosting and domains sit in personal accounts of people who no longer work on the project.
• Security incidents have started. Spam accounts, data exposure or suspicious activity appear in the logs.
• A prototype became production. A quick build, often made with AI tools, now has paying users but no tests, no monitoring and no documentation.

The first 30 days of a takeover

Days 1–5: secure access and assets

Before anyone changes a line of code, make sure the business controls everything the product depends on.

• Source code repositories, with full history, transferred to an organization account the business owns.
• Cloud accounts, hosting, databases and backups, with the business as the account owner.
• Domains, DNS and SSL certificates.
• App store developer accounts and signing keys for mobile apps.
• Third-party services: payments, email, analytics, maps, authentication and AI model APIs.
• Passwords and API keys, rotated as soon as the new team has access, since former team members may still hold them.

If a previous vendor is involved, the transition terms in the original contract decide what they must hand over. Our guide to software development outsourcing agreements explains the clauses that make this step easier.

Days 5–15: audit the system

The audit answers one question: what is the real state of this system? It usually covers seven areas.

The output is a short report with findings ranked by risk and effort, plus an estimate for both rescue and rebuild.

Days 15–30: stabilize

Stabilization makes the system safe to change, before any new features are added.

• Fix the critical security issues found in the audit.
• Set up continuous integration, so every change is built and checked automatically.
• Add automated tests around the flows that bring in money or handle sensitive data.
• Set up monitoring and alerts that point to real problems, not noise.
• Confirm that backups run and can actually be restored.
• Write down how to run, deploy and roll back the system.

Rescue or rebuild: a decision rule

After the audit, score the system on five questions. Each "yes" points toward rescue.

1. Is the data model sound? Data structures are the hardest part to change later. If they fit the business, the foundation is worth keeping.
2. Do the main user flows work? If customers can complete the core journeys, most of the product's value already exists.
3. Are the problems concentrated? Issues clustered in a few modules can be fixed. Problems spread evenly across the code are harder.
4. Is the technology still supported? A current, widely used framework is easier to staff and secure than an abandoned one.
5. Can tests be added without major changes? If critical flows can be covered with tests, the team can change the code safely.

Four or five "yes" answers usually mean rescue is faster and cheaper. Two or fewer suggest a staged rebuild, ideally reusing the data and the parts that work. Three is a judgment call that depends on the budget and on how soon new features are needed.

A full rebuild is rarely the right first move. It stops visible progress for months, and teams that rebuild often recreate the same problems because they have not yet learned why the original system behaves as it does.

Rescuing AI-built applications

Applications built quickly with AI coding tools, often called vibe-coded apps, are a growing share of rescue work. They usually work in a demo and fail under real users, real data and real attackers. In its 2025 GenAI Code Security Report, Veracode tested more than 100 language models on 80 coding tasks and found security flaws in 45% of the results, including weaknesses from the OWASP Top 10.

The same problems appear again and again:

• Secrets in the code. API keys and database passwords stored in the frontend or committed to the repository.
• Permission checks only in the interface. The app hides buttons from users who should not use them, but the server accepts the request anyway.
• Database rules left open. Hosted databases used by AI app builders often rely on row-level access rules that are missing or too broad, exposing other users' data.
• No tests. Every change risks breaking something that worked yesterday.
• Copy-and-paste structure. The same logic repeated in many places, so a fix in one place leaves the bug in others.
• Unbounded AI costs. Calls to language models without limits, caching or error handling, which can produce large bills.

The rescue playbook stays the same, with extra weight on security. Secrets are rotated and moved to a secure store, permission checks move to the server, database access rules are reviewed one by one and tests are added before any refactoring. In many cases, the interface and product logic of an AI-built app can be kept, while the backend, data access and security layer are rebuilt properly.

Rescues from our work

A subscription site inherited from an earlier vendor

Connell Guides, a UK publisher of study guides, had a subscription site built on Drupal 7 by an earlier vendor. Spam registrations and cross-site scripting vulnerabilities threatened the business, mobile pages performed poorly, and the budget was fixed. .wrk started with a security-first sprint, then updated the core and modules, rebuilt the page layouts to be responsive and set up analytics and subscription permissions. The project came in 18% under budget, bounce rate fell to about 4% and on-page engagement rose 14%. Read the Connell Guides case study.

A platform without tests

A B2B supply chain platform had no automated tests, outdated dependencies, silent conflicts when two people edited the same record and dozens of monitoring alerts a day that nobody trusted. .wrk added test suites to every merge request, cleaned up the alerts so only a handful of actionable ones remained, added an audit trail that shows who changed what and when, and then upgraded the frontend framework safely. Read the platform modernization case study.

Integrations that kept failing

A US media company running webcast registration across three brands had a single sign-on setup that broke password managers, event data syncs that hit rate limits and unreliable attendance data. .wrk redesigned the registration flow, replaced constant polling with webhooks and added automated smoke tests that run after every deployment, so integration failures are caught before users notice them. Read the SSO and webcast registration case study.

What a software project rescue costs

These ranges reflect typical mid-size web and mobile products and an experienced team at Central European rates.

The audit is the best-value step in the process. It turns an emotional decision about an unfamiliar codebase into a plan with numbers, and it often shows that much of the existing work can be kept.

How to avoid needing a rescue next time

• Own every account from day one: repositories, cloud, domains and app stores in the company's name.
• Require documentation and tests as part of the definition of done.
• Include transition terms in every development contract, covering code, credentials, documentation and handover support.
• Review AI-built code before it reaches production, especially permissions, secrets and database rules.
• Watch the warning signs: slowing releases, rising bug counts and estimates that keep growing.

Our article on legacy system modernization covers what comes after a rescue, when a stable system needs a longer modernization path.