I built an app with AI and it does not hold: here is what is missing

What happened, and why it is normal

You described what you wanted, the tool produced something that worked, and you were right to believe in it: what you got in a few evenings would have taken weeks three years ago.

Then you wanted others to use it, and everything started to jam. That is not a failure, and it is not your fault. It is simply that the visible part of an application is a fraction of the work, and it is the only part a conversation describes easily.

The four gaps, always the same

Data does not survive. Many prototypes keep information in the browser or in a file that resets. While you are the only one trying, it does not show. As soon as a colleague uses it from their machine, the data diverges — and the day something disappears, there is no backup because there was nothing to back up.

There are no real accounts. A login screen is not authentication. The question is not “how do you get in”, it is “who is allowed to see what, and what technically prevents them otherwise”. In most prototypes the answer is: nothing. All the data is reachable by anyone who knows how to ask.

Nothing handles the abnormal. The form works if filled in correctly. Nobody fills in correctly. Empty field, double click, connection dropped at the wrong moment, a 40 MB file: each produces either an incomprehensible error or, worse, half-written data.

It runs on your machine. Which means it does not run. It is missing hosting, a domain name, a certificate, automatic backups, and a way to update without breaking everything.

What is kept, and what is redone

Almost everything is kept, and that is the good news. What you produced holds the hardest information to obtain in a project: what you actually wanted. The screens, the sequences, your trade’s vocabulary, the edge cases you thought of — all of that has real value, and a specification written cold would never have captured it as well.

What is usually redone: how the data is stored, the accounts and permissions layer, and getting to production. That is not the part you enjoyed, and it is the fastest part for someone who has done it fifty times.

In which order to pick it up

1. 1Freeze what exists. A copy of the code and the data, before any change. It sounds obvious and it is the most frequently skipped step.
2. 2Put in a real database, and move what exists into it. From then on, nothing is lost.
3. 3Add accounts and permissions, before opening to anyone.
4. 4Deploy, with automatic backups and a way to roll back.
5. 5Only then, revisit the features one by one.

The order matters: each step makes the next simpler, and the reverse is not true.

How long

Far less than rebuilding. A working prototype that took you several weeks generally means a few weeks of pick-up work to reach production — and you already know what you want, which removes the most uncertain part of any project.

That is also why it is better not to throw it away. A professional’s reflex on discovering a prototype is to propose starting again cleanly. That is comfortable for them, expensive for you, and it loses the one thing you had that was unique.