A prototype built with AI, how to bring it into the company
What lies between a working demo and an app for real customers, which checks to run, what GDPR asks and when it pays to fix it rather than rebuild it.
Can a company use an app built with AI?
Yes, after a review. Tools such as Lovable, Replit or Claude Code write in a few days an app that works in a demo: you log in, record orders, see customers. A demo, though, is used by one person with fake data, and it does not prove what matters when the others arrive: that everyone sees only their own data, that nobody can change a price from the browser, that the data survives a mistake.
None of the answers that search engines and AI assistants give to this question says to use it as it is. Lovable says so too in its documentation: its security tools help find common problems, but they “cannot guarantee complete security”, and the responsibility for giving the app the security its use requires stays with you.
| What you see in the demo | What real users need | What happens if it is missing |
|---|---|---|
| Login works | roles and permissions: who sees what, who edits | an employee or a customer sees what they should not |
| The data shows up | each customer's data separated in the database, not just hidden by the interface | a customer reads another's orders by changing a number in the request |
| The features respond | keys and passwords only on the server | whoever opens the page code finds the key and uses it |
| The total is right | prices and rules computed on the server | an order of 1,000 € goes through at 1 € by editing the request |
| The data is there | automatic backups and a restore already tested | after a mistake or a deletion the data does not come back |
| The app runs | a separate test copy, alerts when something breaks | a change breaks production and you hear it from customers |
| You built it | a person who answers for it and keeps it updated | when something breaks nobody knows who has to step in |
A demo proves that the idea works; the review proves that the app holds up for the people who really use it. The rest of the guide covers what can go wrong, how to check it yourself, what GDPR asks, when to fix and when to rebuild, and what it costs.
What can go wrong?
The most frequent risk is also the most serious: one customer reads another's data. It happens when the interface shows each customer only their orders, but the database hands them to anyone who asks. In apps that rest on Supabase, such as Lovable's, the protection is called Row Level Security: rules that say, row by row, who can read and who can write. Supabase's documentation is blunt: an exposed table without these rules can be read and modified, and they must be enabled on every exposed table.
The most cited case has been measured. On 20 March 2025 Matt Palmer, an independent researcher, found that many apps published in the “Lovable Launched” showcase let people without the right read sensitive user data, and insert fake data: of 1,645 apps analysed, 170 had exposed endpoints, 303 in all. The cause was Row Level Security rules that did not match what the interface showed. The issue is registered as CVE-2025-48757, and Lovable disputes it: according to the platform, protecting the data of each app is up to whoever builds it. The same 10.3% circulates online attributed to a “HackNope audit of December 2025” that cannot be found: the measurement is Palmer's.
Apps in the Lovable Launched showcase with exposed data
170 apps out of 1,645 analysed, with 303 exposed endpoints.
Source: Matt Palmer, “Statement on CVE-2025-48757”, 29 May 2025
The other risks are less spectacular and just as common. The examples are illustrative, but they are the ones that recur in the engines' answers and in the Supabase and Lovable guides.
| What happens | An example | How to check it |
|---|---|---|
| A customer reads another's data | they change order 1041 to 1042 in the request and see another company's order | two test accounts, each looks for the other's data |
| A secret key reaches the browser | the Supabase key that bypasses every rule, the service_role, is in the page code |
search the published code; if it is there, move it to the server and rotate it |
| A rule lives only in the interface | the price or the discount can be changed in the request | send the edited request and see whether the server rejects it |
| An access stays open | an employee who left can still log in | list of users and roles, revoked on the day they leave |
| An order goes through twice | a double click on “Confirm” creates two orders and two charges | repeat the same request and count the orders |
| A backup does not restore | the backup exists, but nobody has ever brought it back | a test restore on a copy, timing how long it takes |
Is code written by AI less secure?
More often yes, and the measurements say so with numbers other than those that circulate. Veracode gave 80 coding tasks to more than 100 models: when there was a choice between a secure solution and an insecure one, the models chose the insecure one 45% of the time. It does not mean, as is often written, that 45% of generated code fails in production.
Tasks in which the model chose the insecure solution
80 coding tasks, more than 100 models.
Source: Veracode, 30 July 2025 press release on the 2025 GenAI Code Security Report
CodeRabbit compared 470 pull requests, that is proposed changes to the code: 320 written with the help of AI and 150 by people alone. In those written with AI it found on average 10.83 issues each against 6.45, about 1.7 times as many, and security issues up to 2.74 times more frequent.
Issues found on average per pull request
issues per pull requestOut of 470 pull requests, 320 written with the help of AI and 150 by people alone. Source: David Loker, “State of AI vs Human Code Generation”, CodeRabbit, 17 December 2025
So the point is not who wrote the code, but who checks it before it reaches customers. We use AI every day too, and the rule is written in our FAQ: code written with the help of AI is reviewed by a person who answers for it, and a model is never the last check before production.
Would you rather talk it through?
Book a call with people who work on these topics every day: we will look at your case together.
How do you tell whether your app is ready?
Answer eight questions: every no is a job to do before opening the app to others. The first four protect your customers' data, and with a no on any of them the app does not go into production.
| Question | How to check it | If the answer is no |
|---|---|---|
| Does each customer see only their own data? | with two test accounts, each looks for the other's data, including by changing the identifiers in the requests | access rules on the database, table by table |
| Do keys and passwords stay only on the server? | look for secret keys in the code that reaches the browser | move them to the server and rotate them |
| Does the server decide prices, discounts and permissions? | edit a request from the browser and see whether it goes through | move the rule to the server |
| Is someone who left the company locked out? | compare the active users with the people who work with you | roles and a revocation procedure |
| Do you have a backup you have already restored? | bring it back on a copy and time how long it takes | automatic backups and a restore test |
| Do you test changes away from customers? | check whether a separate test copy with fake data exists | a test environment |
| Do you know when something breaks? | check whether errors reach someone | monitoring and alerts |
| Does someone answer for it? | there is a name, not “whoever built it” | a person inside, or a supplier with a contract |
If you built it with Lovable, its security scan is a good start. The quick one runs at every publish and checks the database access rules, libraries with known vulnerabilities and MCP servers your app exposes without authentication; the deep one reviews all the code, looking among other things for users who can see or change data that is not theirs, keys left in the code and prices a customer can change. Lovable's documentation also says where they stop: these tools do not replace a thorough security review, and for an app handling sensitive data it recommends an additional professional review.
Does the tool you used change anything?
It changes where code and data live, and how you take them away; the checks stay the same.
| Tool | What it does | Where code and data live |
|---|---|---|
| Claude Code | reads your code, edits files and runs commands, from the terminal, the editor, the app or the browser | the code in your repository, the database you choose |
| Lovable | builds the app from a conversation | the database in the included backend, Lovable Cloud, built on Supabase, or in your own Supabase project; the code syncs with GitHub |
| Replit | its agent writes the code, sets up the infrastructure, configures the database and publishes the app | on Replit, where the agent configures the database and publishes the app |
| Bolt | builds websites and apps, including internal tools and dashboards | the database in Bolt Database, publishing on Bolt Cloud |
| Cursor | an agent that works on your code: explains it, builds features, fixes bugs | the code in your repository, the database you choose |
With Lovable, connect the project to GitHub right away: the sync runs both ways, leaves you a copy of the code outside the platform, and it is from there that the reviewer reads it. If you disconnect it, later changes stay only inside Lovable. If the app uses Lovable Cloud and one day you want to move it to your own Supabase project, it is manual work: the database is exported, and authentication, files, secrets and integrations are set up again.
Where does the data live, and who makes the backups?
First of all, know where it is: in which service, in which country, under which contract. If a supplier processes your customers' data on your behalf, GDPR asks you to choose one that gives sufficient guarantees and to govern the relationship with a contract (article 28).
Then the backups. If the app uses your own Supabase project, they depend on the plan.
| Supabase plan | Price | Automatic backups |
|---|---|---|
| Free | free | none; the project is paused after one week without activity |
| Pro | from $25 a month | daily, kept for 7 days |
| Team | from $599 a month | daily, kept for 14 days |
Restoring to a precise moment, instead of to last night's backup, is an add-on at $100 a month for every 7 days of history. Whatever the tool, there are two questions: where are the backups, and who knows how to restore them. GDPR asks for the ability to restore data in a timely manner after an incident and for a process to regularly test that the measures work (article 32), that is a tested backup, not just one switched on. As we say in the FAQ on backups, a backup only the supplier can restore is not a backup, it is another dependency.
What does GDPR ask if the data leaks?
To notify the supervisory authority, in Italy the Garante, within 72 hours of becoming aware of it, unless a risk to people is unlikely, and to warn the people involved as well if the risk is high. Every breach must be documented, even one you do not notify. If your app holds customers' names, emails or orders, that is personal data, and you are the controller.
| Obligation | What it asks | Where |
|---|---|---|
| Security appropriate to the risk | technical and organisational measures, including the ability to restore data and a process to regularly test that the measures work | article 32 |
| Notifying the authority | without undue delay and, where feasible, within 72 hours of becoming aware of it, unless the risk to people is unlikely; after 72 hours, with the reasons for the delay | article 33 |
| Documentation | every breach, with its facts, its effects and the remedial action, even if you do not notify it | article 33, paragraph 5 |
| Telling the people involved | if the risk is high, without undue delay and in clear and plain language | article 34 |
| A contract with whoever processes the data for you | a supplier with sufficient guarantees, and a contract that governs the relationship | article 28 |
Google's AI Overview and AI Mode cite the fine of up to 4% of turnover. For security and notification obligations the cap is another one: up to 10 million euro or 2% of total worldwide annual turnover, whichever is higher (article 83, paragraph 4). The 4%, or 20 million, applies to the principles, including the one requiring data to be processed with appropriate security (article 5): a serious breach can fall there too. The average cost of a breach that many answers cite, 4.44 million dollars in 2025 according to IBM, also comes from 600 organisations worldwide and does not say what it would cost your company.
A technical contribution
The rules are summarized from the text of the regulation published by the Italian Data Protection Authority, read on the date at the top of the page. Like the other guides, this is a technical contribution, not legal advice.
Should you fix it or rebuild it?
The review decides, not the tool you built it with. The answers you find online split: Google's AI Mode says to rebuild it; ChatGPT, Perplexity and the English AI Overview say to fix it after a check. Those that explain why use the same criterion we use, the data model and the permissions. If the tables are well designed and the protection is missing, it is added; if all customers' data is mixed together and the rules live in the interface, every fix calls for another.
| What the review finds | What pays off |
|---|---|
| data separated per customer, rules to add or tighten | fix it |
| a good interface, database or permissions to rethink | keep the interface and rebuild the part that holds the data |
| rules and calculations in the browser, mixed data, links to the management system or payments still to be built | rebuild it, with the prototype as the specification |
| an app that a ready-made product already does, or that is no longer needed | stop |
If fixing it costs more than 10,000 €, rebuild it: that is the figure an MVP built by us starts from. In neither case is the prototype thrown away, because it is the clearest specification you can give whoever rebuilds it: screens, fields and flows you have already tried. If you wonder whether you really need a custom app, the comparison with ready-made tools is in the article Low-code, no-code or code.
What does it cost to take it into production?
With us the review costs 2,500 € at a fixed price and takes one week; if you then give us the work, we deduct it from the quote. Fixing it usually costs between 5,000 and 10,000 €, rebuilding it from 10,000 €, like an MVP: these are our estimates, and the figure for your case comes out of the review.
| Item | How much | What you get |
|---|---|---|
| Review | 2,500 € at a fixed price, in one week, deducted from the work if you go ahead | the problems ranked by severity, the choice between fixing, rebuilding or stopping, the quote for the work |
| Fixing it | 5,000-10,000 € in 2-4 weeks, estimate | the checks in the list above put right: permissions, keys, backups, environments, alerts |
| Rebuilding it | from 10,000 €, like an MVP | an MVP in production, with the prototype as the specification |
To the same question, asked on the same day, the engines give figures that differ from one another, and none says where they come from. Google's AI Mode, asked twice, gave two different ranges for rebuilding.
| Who answers | Fixing it | Rebuilding it |
|---|---|---|
| Google AI Overview | 3,000-7,000 € | 12,000-25,000 € |
| Google AI Mode | over 30,000 € | 15,000-25,000 €, on the second request 15,000-30,000 € |
| ChatGPT | 3,600-10,700 €, on the second request 3,000-8,000 € | 12,000-30,000 € and more |
| Perplexity | 1,500-4,000 € of review and 3,000-10,000 € of production work, 8,000-20,000 € in all | no estimate |
| Volcanic Minds | 2,500 € of review, then 5,000-10,000 €, estimate | from 10,000 € |
Answers collected on 29 October 2026 to the question, asked in Italian, of a 25-person company with an orders and customers app built with Lovable. Think about subscriptions straight away: hosting, database and external services are your costs, and it pays to know them beforehand.
Who maintains it after release?
A person with a name, inside the company or at a supplier. Among the 161 pages the engines cite on this question, which we read one by one, only one asks it. An app in production must be updated, because the libraries it rests on receive security fixes; it must be watched, and every change must be tested before it reaches customers. With an AI tool a change is easy to make and just as easy to get wrong.
With us, on fixed-price projects, there is one month of warranty for blocking bugs and minor work. After that, maintenance continues only if you want it, with a dedicated contract and SLAs, and we estimate it on the work the app really needs, not as a percentage of the initial cost. For a simple management system, like the garage one in the cost guide, maintenance costs about 2,500 € a year and hosting, on top, from 950 € a year; what it covers is in the guide Maintaining custom software and AI. The code stays yours, and the data can be exported without going through us. If the app has to become a subscription product, with each customer's data isolated, that is the work we describe in SaaS development.
If you built it yourself and are choosing whom to hand it to, the risks of a custom project and what to write into the contract are in the guide Risks of a custom software project. For developers, the comparison between the tools is in the article Vibe coding.
Sources and further reading
- Lovable, “Security”, documentationdocs.lovable.dev, accessed 29 October 2026
- Matt Palmer, “Statement on CVE-2025-48757”, 29 May 2025mattpalmer.io, accessed 29 October 2026
- CVE-2025-48757, National Vulnerability Database entrynvd.nist.gov, accessed 29 October 2026
- Supabase, “Row Level Security”, documentationsupabase.com, accessed 29 October 2026
- Veracode, “AI-Generated Code Poses Major Security Risks in Nearly Half of All Development Tasks”, 30 July 2025veracode.com, accessed 29 October 2026
- David Loker, “State of AI vs Human Code Generation”, CodeRabbit, 17 December 2025coderabbit.ai, accessed 29 October 2026
- Claude Code, “Overview”, documentationcode.claude.com, accessed 29 October 2026
- Lovable, “Lovable Cloud”, documentationdocs.lovable.dev, accessed 29 October 2026
- Lovable, “GitHub integration”, documentationdocs.lovable.dev, accessed 29 October 2026
- Replit, “Replit Agent”, documentationdocs.replit.com, accessed 29 October 2026
- Bolt, help centersupport.bolt.new, accessed 29 October 2026
- Cursor, documentationcursor.com, accessed 29 October 2026
- Supabase, pricingsupabase.com, accessed 29 October 2026
- Regulation (EU) 2016/679, articles 5, 28, 32, 33, 34 and 83, in the text published by the Italian Data Protection Authoritygaranteprivacy.it, in Italian, accessed 29 October 2026
- Italian Data Protection Authority, “Violazioni di dati personali (data breach)” (Personal data breaches)garanteprivacy.it, in Italian, accessed 29 October 2026
- IBM, “IBM Report. 13% Of Organizations Reported Breaches Of AI Models Or Applications”, 30 July 2025newsroom.ibm.com, accessed 29 October 2026
Is an app built with Lovable safe for customer data?
It can be, but a working demo does not prove it. You need to check that each customer sees only their own data, with Row Level Security rules enabled on every table, that secret keys do not reach the browser and that the server decides prices and permissions. In 2025 a researcher found exposed data in 170 of the 1,645 apps analysed in Lovable's showcase.
Is Lovable's security scan enough?
No. It is a good start, and the deep version reviews all the code, but Lovable's documentation says these tools do not replace a thorough security review and recommends a professional review for apps that handle sensitive data. Responsibility for the app's security stays with whoever publishes it.
What does it cost to put an AI-built app into production?
With us the review costs 2,500 € at a fixed price, takes one week and is deducted from the work if you go ahead. Fixing it usually costs between 5,000 and 10,000 €, rebuilding it from 10,000 €; these are estimates, and the figure for your case comes out of the review.
Should I fix the app or rebuild it from scratch?
It depends on the data model and the permissions, not on the fact that an AI wrote the code. If the data is separated per customer and only the protections are missing, you fix it; if data and rules are tangled in the interface, it pays to rebuild it. If fixing it costs more than 10,000 €, rebuild it, using the prototype as the specification.
If my customers' data leaks, what do I have to do?
If there is a risk to people, you notify the breach to the supervisory authority, in Italy the Garante, within 72 hours of becoming aware of it, and if the risk is high you also warn the people involved (articles 33 and 34 of GDPR). Every breach must be documented, even one you do not notify.
Who is responsible if an AI-built app loses data?
You, as the controller, not the tool you built it with. Lovable says so in its documentation, and Lovable itself disputed the CVE-2025-48757 vulnerability on the grounds that protecting the data of each app is up to whoever builds it.
Do you have a prototype built with AI?
Tell us what it does and what you built it with. In one week, at a fixed price, you receive the problems ranked by severity, the choice between fixing and rebuilding and the quote for the work.
- You won't talk to a salesperson
- NDA before we get into the details
- The code stays yours
Articles on the same topics.
Web Bot Auth: visitors with no eyes
AI agents read your site and convert better than organic, yet they never show up in analytics. How to measure them and verify them with Web Bot Auth.
Read
Generative UI: for humans and machines
Explore how Generative UI and Dual-Interaction UX transform enterprise SaaS by creating adaptive interfaces for human operators and AI agents.
Read
Multi-tenant: SaaS data segregation
What multi-tenant means and how to pick data isolation in a SaaS: dedicated database, separate schema or shared row, and what changes with AI and RAG.
Read