The scenario has become common. An idea, a weekend, an AI code generation tool, and a few days later an app that works. The first users arrive, and so does the excitement. Then come the first signs: a page that takes ten seconds to load, data that vanishes, a harmless change that breaks three other things, and the growing feeling that nobody, not even the AI, really understands what is going on in the code. If that is where you are, take heart: it is neither rare nor necessarily serious. But it has to be handled with method.
Why it works in the demo and not in production
Code generation tools are remarkably good at producing something that works in the expected case: one user, clean data, a path mapped out in advance. A demo, in short. Production is everything else: a hundred users at once, a connection dropping mid-payment, a field left empty, someone trying to reach another person’s data. These cases never show up in a demo, and code generated without them in mind does not handle them. It is exactly the distinction we have defended from the start: a product, never a demo.
The symptoms that never lie
Some signs come back on almost every app handed to us in this state:
- Fixes that break other things: the code grew in successive layers, with no overall architecture
- Secrets in the code: API keys or database passwords, visible to anyone who inspects the app
- Access checks on the screen only: the interface hides a button, but the server accepts the request from anyone
- Slowness that grows with the data: queries that load everything instead of fetching what is needed
- No tests, no readable history: no way to know whether a change breaks something before users find out
The second and third points need immediate attention. A slow app costs you users; an app that leaks personal data costs far more, in trust as much as under the GDPR.
Diagnose before you rewrite
Faced with code nobody understands any more, the temptation is to throw it all away. That is rarely the right first decision. A rescue starts with an audit: reading the code, mapping what exists, measuring what is actually used, spotting the security holes, and above all understanding what the app does well. Because an AI-generated prototype often has real value: it has validated a need, settled a user journey, sometimes found its first customers. That knowledge is not something you throw away.
The audit produces a clear map: what can stay as it is, what needs strengthening, what needs rewriting. In most cases, the verdict is neither ‘throw it all away’ nor ‘all is well’, but focused work on a handful of critical areas.
Strengthen it or start from scratch
Starting from a blank page is justified in specific situations: when the data structure is fundamentally unsuited, when the security holes are so widespread that safety can no longer be guaranteed, or when the product has changed direction so much that the code no longer matches anything. Outside those cases, gradual strengthening almost always wins: secure it first, put tests on the journeys that matter, then rework the fragile areas one by one, without interrupting the service. Users do not see the work, they only see the app becoming reliable.
AI-generated code is not the problem. The problem is code nobody reviewed, tested or understood before putting it in the hands of real users.
AI is still a good tool, in the right place
None of this is an indictment of AI. We use it ourselves every day, to write code, review it and explore options. The difference lies in the place you give it: an accelerator in the hands of someone who can judge what it produces, not a replacement for that judgement. It is the thread running through our approach to AI: the tool in service of the product, never the reverse. And for what comes next, the lesson is worth keeping: an MVP with a well-framed scope, built to last, costs less than a quick prototype you have to rework six months later.
If your app was built fast and is starting to give way, this is not the moment to panic, nor to start over blindly. It is the moment for an honest assessment. It is work we do regularly in product engineering: taking over an existing codebase, securing it, making it maintainable, without losing what it has already proved. Tell us about your app: we will start by telling you what, in our view, is worth keeping.