A customer portal, an order tool, a report everyone can finally open themselves: with AI tools, even staff who have never programmed now build working applications. That is good news. Someone who knows the workflow often builds something that fits better than any standard software.
The application looks finished, and in the demo everything works. What the demo does not show: how it behaves when real customer data is in it, twenty people use it at the same time and someone deliberately looks for gaps.
What people build with today
The tools fall roughly into two groups:
- Browser-based builders such as Lovable, Bolt, Replit or v0. You describe what you need and get a running application including a database, often with a service such as Supabase or Firebase in the background.
- Coding assistants such as Cursor, GitHub Copilot or Claude Code. They write code on instruction, mostly for people who already have some experience.
Both get you to a result quickly. The gaps discussed here are not the result of sloppiness. The tools are designed to make something work - not to make it secure, traceable and maintainable.
Six typical gaps
Access: who can get at the data?
Many applications built with AI have a proper sign-in page but no check behind it. The interface hides buttons, but anyone who calls the addresses in the background directly still gets the data. With database services such as Supabase, the keyword is row level security: if it is not set up, anyone with the application’s public key can often read the tables.
Credentials: what is in the code?
Keys for the database, the payment service or the AI service easily end up in the code that reaches the browser. Any visitor can read them there. A key to an AI service is then used on your bill.
Data: where does it go?
Which services the application uses may well have been decided by the tool. Customer data then sits with a database provider, text goes to an AI service, emails through a delivery service - often outside the EU and often without being written down anywhere. Your data protection officer should know the list before real data flows. And: is there a backup that has actually been restored once?
Changes: what happens at the next rebuild?
Tell the AI to “rework this” and it often changes more than you asked for. Without a test environment, every change goes straight to everyone who uses the application. And without version control, there is no way back to yesterday’s version - except asking the AI to undo everything.
Errors and costs: who notices?
The application reports errors nowhere. They get noticed when someone complains. At the same time, AI services and many hosting providers bill by usage. A fault in the program or outside access then shows up first on the credit card statement.
Dependency: who still understands it?
The application grew out of many instructions to the AI, and nobody has read the code - sometimes not even whoever built it. If it then sits in an employee’s personal account or only inside the tool, the application is not an asset but a liability.
Retrofit rather than rebuild
The good news: these gaps can usually be closed without throwing the application away. Something that works and that staff have accepted is worth a lot. Typical additions are:
- permission checks on the server instead of only in the interface
- keys out of the code and into a safe place
- a test environment and version control
- backups that are tested
- alerts on errors and caps on costs
- a short description of how the application is built
None of this happens by itself, though. What matters is knowing the gaps before real data goes in - not afterwards.
Check it yourself
Our production readiness check asks twelve questions on exactly these points, each with a standard for done and one for open. No sign-up and no email address, and your ticks stay on the page. Some questions are best answered by whoever built the application.
