An application built with AI that nobody understands any more
It runs, and you use it every day. But the day it breaks, who knows how it works?
How it happens
One day, someone described to an AI assistant what the business needed: you, a colleague or a freelance developer. Soon after, the application was running. It was quick, it worked, and it was probably the right call.
Then the needs changed. Every change went back to the AI, layered on top of the last one. Today the application runs part of your business, and nobody can explain how it is built.
- Every fix breaks something else.
- Nobody really knows where the data lives, or how to get it out.
- The person who built it has moved on, no longer has the time, or no longer dares to touch it.
- Nobody knows which accounts and subscriptions keep it running, or whose name they are in.
What a quickly built application often lacks
Neither the AI nor the person who used it is to blame. It is what gets skipped when you go fast, and what no tool does for you.
-
No tests
Nothing checks that a change does not break what used to work. You find out when a customer calls.
-
No documentation
No map, no explanation. To understand it, someone has to reread all the code, or ask the AI again, which starts from scratch.
-
Secrets in the code
Passwords and access keys written in plain text in the code, and sometimes published with it.
-
Muddled data
The same information in several places, under several names. Two screens give two different figures.
-
Forgotten dependencies
Libraries added along the way, still on their first-day version, with their known security flaws.
-
Nobody responsible
When it goes down on a Friday evening, who answers? An AI does not pick up the phone.
What it really costs you
A quickly built application is cheap to make. It can be expensive to keep.
- How long did the last fix take, and what did it break elsewhere?
- If the application stops on Monday morning, who do you call, and how long do you wait?
- If an access key leaked with the code, who would notice, and when?
- If a customer or someone looking to buy your business asks where your data is and who can access it, what do you answer?
Why not just ask the AI again?
Code has become a commodity. The value lies in the architecture, the diagnosis and the responsibility.
An AI writes code very fast. It can even write you a fine report on yours. But it does not tell you which points to act on first, or what each one costs you. It does not see what your teams do around the tool. And it does not answer for its decisions.
AI is multiplying the applications that nobody understands any more. Taking them over needs what it does not provide: someone who reads the whole thing, decides what has to change first, and takes responsibility for it.
That does not make your application worthless. It holds your business rules, tested by real use. It is something to build on, not a mistake.
Secure it this week
Six checks that do not touch the code. Useful even if you never call us.
- The code. Check that it is in a repository (GitHub, GitLab or another) in your company's name, not only on someone's computer or personal account.
- The accounts. List the ones the application depends on: hosting, database, domain name, AI services, payments, e‑mail. Write down who holds each one and who pays for it.
- Backups. Back up the database, and check that the backup can be restored.
- Secrets. Look for passwords and keys written in the code or pasted into conversations with the AI. If there are any, have them changed by someone who knows where the application uses them, or it goes down.
- The conversations. Keep the chats and instructions used to build the application: for now, they are its only documentation.
- Going live. Write down who can put a new version online today, and how.
The full checklist, with access and domain names: legacy application takeover.
What we do, and in what order
The three-step takeover: scope, stabilize, rebuild. It all starts with a health check: in two weeks, you know what the application costs you and what will break first.
-
Scope
We read the code and the hosting, and look for exposed secrets, duplicated data and risky dependencies.
The health check -
Stabilize
First the urgent fix, for example moving the secrets out of the code, then what pays back the most, at a fixed price. Every fix comes with its documentation.
Stabilize
Where to start?
Your application was not built with AI, but nobody touches it any more? See your team has no time, or your developer has left.
Every situation: legacy application takeover.