Taking over an AI-built or inherited app? Triage first, fix second

Taking over an AI-built or inherited app used to start with a slow hunt for problems. Now an automated scanner can produce a long list of findings in an afternoon, so finding flaws is no longer the bottleneck. What matters is judgement: securing ownership, rotating secrets and fixing the few issues that genuinely put your business at risk, before anyone talks about a rebuild.

What does the OpenSSL bug-report flood tell you about inherited code?

OpenSSL, one of the most widely used pieces of internet security software, is being buried in reports. According to Axios, the project received an average of 71 security reports and inquiries per month between May and July, up from nine during the same period last year. Many were duplicates, minor bugs or issues that didn't warrant a security advisory, and most of the flaws AI tools found were low-severity. Every one still needed a person to review it.

Axios points to the bigger issue: the flood is exposing a shortage of experienced engineers who can tell which flaws are real threats.

The same thing plays out on a smaller scale when you inherit an app. Point a scanner at a vibe-coded codebase, or one left behind by an agency or freelancer, and you'll get pages of warnings. Finding flaws has become cheap; deciding which ones matter has not. A long report can leave a business either falsely reassured or needlessly panicked, and neither is the right response until someone has separated the noise from the risk.

Finding flaws has become cheap; deciding which ones matter has not.

Why should ownership come before code review?

Before anyone reads a line of code, check who actually controls the system. It's common for a former developer or agency to still hold the keys. Make sure your business, not a third party, controls:

• the code repository and its full history
• hosting and cloud accounts, with billing in your name
• the domain name and DNS
• app store developer accounts, if there's a mobile app
• database backups, and proof they can be restored
• third-party services the app relies on, such as payments, email sending and AI model APIs

If any of those sit in someone else's account, fix that first. A secure app you can't deploy, renew or restore is still a risk to your business.

Why rotate every password and API key on day one?

Leaked credentials are one of the most practical risks in AI-built code, and they don't expire on their own. IBM's write-up cites a 2026 GitGuardian report finding that Claude Code-assisted commits exposed secrets more than twice as often as human-only commits. It also shows how long leaked credentials stay useful: almost 70% of credentials confirmed as real in 2022 were still valid through January 2025, and 64% were still exposed and unrevoked as of January 2026.

A change of ownership is the natural moment to deal with this. Assume every key, password and token in the codebase, its history, old environment files and the previous team's machines has been seen by someone. Rotate them all, move them into a proper secrets store or your hosting platform's configuration, and remove access for anyone who no longer needs it. It's one of the cheapest, highest-value jobs in any takeover.

How do you triage scan results instead of trying to fix everything?

Run the automated scans, by all means. Then rank every finding against two questions:

1. Can it be reached from the internet? A flaw in a public login page or API matters far more than one in an internal script nobody outside can reach.
2. Does it touch personal or financial data? Anything involving customer records, payments or logins goes to the top, given your obligations under UK data protection law.

Findings that fail both tests can usually wait. Expect a good share of the list to be duplicates, false alarms or low-severity issues, just as OpenSSL's maintainers found.

Then look at what the app depends on. List every third-party library and package, check that each one genuinely exists, is still maintained and is a reasonably current version, and remove anything unused. AI tools pull in packages freely, and inherited projects often carry dependencies nobody remembers adding.

The NCSC's vibe coding spectrum is a useful frame here: think carefully about what you're building, understand the risk, and adjust your approach accordingly. An internal prototype and a customer-facing portal holding personal data deserve very different levels of scrutiny.

Should you stabilise the app or rebuild it?

When an inherited app is messy, rebuilding feels tempting. It's often the wrong first move. The UK public sector shows what happens when old systems pile up unmanaged: the Public Accounts Committee warned of "a worrying lack of urgency in addressing the long-standing issue of legacy IT systems", as The Register reported, and inspectors found the National Crime Agency relying on 260 legacy IT systems, with technical debt making up 80 percent of its IT budget.

But the lesson isn't to throw systems away. Research from Ensono, reported by IT Brief, found 57% of UK organisations are extending legacy systems rather than replacing them, with AI increasing the value of platforms that hold years of operational data and business logic. That survey covers larger organisations, but the reasoning carries over: the app you inherited probably encodes how your business actually works, warts and all.

So stabilise first:

• add monitoring and error alerts so you know when something breaks
• confirm backups run and can be restored
• write a short runbook covering how to deploy, where everything is hosted and who to contact
• document the main data flows and integrations

Once the app is stable and understood, you can make an informed call on which parts genuinely hold you back, and rebuild only those.

How should the fixes actually be delivered?

In short sprints, highest risk first. A cycle that closes the worst internet-facing issue, then the next, keeps progress visible and lets you re-prioritise as you learn more about the codebase. Inherited code always holds surprises, so a fixed plan written on day one rarely survives contact with it. That's why HeyIO works this way on takeovers: working software early, priorities agreed as we go (see how we work).

What should you do next?

If you've inherited an AI-built or agency-built app, work through it in this order:

1. Confirm your business owns the repository, hosting, domain, accounts and backups.
2. Rotate every secret and move them out of the code.
3. Scan, then triage by internet exposure and personal data.
4. Audit the dependencies.
5. Stabilise and document before deciding what to rebuild.
6. Fix in short sprints, worst first.

Our free AI app launch checklist covers many of the same checks. If you'd like experienced eyes on the triage, our AI prototype to production service is built for exactly this, and our consultancy team offers architecture reviews and ongoing support.