A pattern we are seeing more every month: a growing company has one capable person, often not a software engineer, who uses AI coding tools to build something the business needed. A quoting tool. A scheduling app. A dashboard that pulls from three systems. It works. People use it. Within a year it is running a real part of the company.
That is a good thing. It is also the moment the risk changes, and most companies do not notice.
What the person built, and what they did not
An AI-built system usually does the visible job well. The screens exist, the logic runs, the data comes out. What tends to be missing is everything you cannot see from the screen:
- A second person who understands it. The builder knows why every piece exists. Nobody else does, and the AI that helped write it does not remember either.
- Source control and environments. Often the only copy of the code is on one laptop, and changes go straight to the version people are using.
- Tests. Changes are checked by clicking around. That works until the change touches something the builder forgot about.
- Access and security. Credentials in the code, everyone an admin, no record of who changed what.
- A path to change it. Adding a feature means the builder finding a weekend. When the builder is busy, the business waits.
None of this is a criticism of the person. Professional teams have to build these things deliberately, and a capable person working alone with an AI tool was never asked to.
When it becomes a continuity problem
The risk is not that the system will fail tomorrow. It is what happens when the one person who understands it leaves, gets promoted, goes on leave, or simply has other work. At that point the company depends on software that nobody can safely change, and the options narrow to “leave it alone” or “rebuild it from scratch.”
You can tell you are close to this point when:
- A change everyone agrees on has been waiting for weeks because the builder has not had time.
- A bug appears and the fix is “restart it” or “do that part in a spreadsheet for now.”
- Someone asks for a report from the system’s data and the answer is that only the builder can get at it.
- You have started to think of the builder as irreplaceable.
What to do about it
The answer is usually not to throw the system away. It is to find out what you actually have, then make it safe to depend on.
Get an independent look. Start with a System Evaluation, scoped to the system you have. For an AI-built tool that is usually a short engagement, and it answers four questions: what does this system actually do, how is it built, what would break if the builder disappeared tomorrow, and what would it take to make it something the company can rely on. You get written findings and a prioritized list, whether or not you do anything else with us.
Fix the foundation first. Source control, a separate place to test changes, backups, access that is not everyone-is-admin, and enough documentation that a second person could pick it up. This is a few weeks of work and it removes most of the continuity risk without touching what users see.
Then decide what it becomes. Some AI-built systems are prototypes that proved the idea and should be rebuilt properly, which is what New Product Development is for. Others are close enough that a modernization in slices is the right call. A few are fine as they are once the foundation is in place, and we will say so.
Keep the builder. The person who built it knows the business and the problem better than anyone. The goal is to give them a team and a safety net, not to replace them.
The honest version of the trade
Building your own system with AI tools was almost certainly the right call. It was cheap, it was fast, and it solved a real problem before anyone else would have. The trade is that you now own a system built without the things professional software carries, and the bill for those comes due when the system matters most.
Paying that bill early is much cheaper than paying it in a crisis. If a system like this is already part of how your company runs, the first step is finding out exactly what you are depending on. That is a short evaluation, not a project, and it is where we would start.