Before your AI-built app goes to your colleagues: a checklist
Before colleagues use an app built in Lovable, Cursor, Claude Code or Replit, check who can get in, where the data and keys are, how changes go live, what happens when it breaks and who looks after it. 24 checks, each with a way to verify it yourself.
For whoever built the app and for the IT person approving it. Tick the checks off here or print the list.
Updated 22 October 2026
of tested coding tasks where AI models wrote code with a vulnerability from the OWASP Top 10.
Lovable apps let anyone read their database without signing in, because the RLS rules were missing (CVE-2025-48757).
publicly reachable apps from Lovable, Replit, Base44 and Netlify found by RedAccess, around 5,000 of them with sensitive data.
0/24 done · 0/9 of the must-haves
Who can get into the app?
An app anyone with the link can open doesn't belong in a company, however good it is otherwise.
-
01
Always before launch
Open it, and pages like
/admin, in a private window off the company Wi-Fi. What you see there, anyone with the link sees. -
02
Your own domain doesn't necessarily switch off
*.lovable.app,*.replit.app,*.vercel.appor*.netlify.app. Try that address too. -
03
Always before launch
Try signing up with a private email: if that works, the app is effectively public. With a company Google or Microsoft account, access ends with the account.
-
04
Check whether someone who left or changed roles can still get in. With the app's own passwords, access is removed by hand, and that gets forgotten.
-
05
Always before launch
Sign in with the lowest role, change the record ID in the address and try the admin section. Permissions belong on the server; a hidden button stops no one.
Where does the data live, and who can reach it?
Usually wherever was quickest during the build: the builder's own account.
-
06
Always before launch
Supabase, Lovable Cloud, Firebase, Google Sheets: whose account, whose card? Data on the author's private account leaves with them.
-
07
Always before launch
On Supabase the browser queries the database directly, and only RLS rules decide who sees what. Check that every table has RLS and policies; the Security Advisor helps.
-
08
Names, salaries, contracts, ID numbers, health data? That decides how tightly it must be closed, and personal data means GDPR applies.
-
09
Go through the AI, email, analytics and payment services in
.env.example. Company data should only reach services the company has a contract with. -
10
How often, kept how long, and has anyone actually restored from one? A backup nobody has restored from is an assumption.
Where are the keys and passwords?
The most common shortcut in AI-built apps is leaving keys in the code.
-
11
Always before launch
Search the repository history for
service_role,sk_,api_keyor a.envfile, or let gitleaks do it. A key that was ever committed counts as leaked; replace it. -
12
Always before launch
Press F12 and search Network and Sources for payment or AI keys. Only public ones belong there, like Supabase's anon key.
-
13
If a key had to be replaced tonight, could someone do it without the author?
How does a change get into production?
With AI, a new version takes minutes. What happens before colleagues see it?
-
14
Always before launch
Your company's GitHub or GitLab, with at least two people having access? Without the code, the app can't be fixed or handed over.
-
15
Can a change go out without a second person seeing it? In Lovable, any editor can publish straight from the chat.
-
16
Is there a test version with its own database? When AI edits one thing, it sometimes changes another.
-
17
Trace the last three deployments: when, what and who. When something breaks, the first question is what changed.
What if something goes wrong?
Every app breaks at some point. The difference is whether you find out first, or your customers do.
-
18
Who would notice on a Saturday? Without error tracking, users find out first and quietly go back to the spreadsheet.
-
19
After a leak you'll need this first, and it can't be filled in after the fact.
-
20
Write down who decides on reporting. A personal data breach generally goes to the authority within 72 hours; under the Czech Cyber Security Act, a significant incident within 24.
Who will look after the app?
“So the fundamental question is who will be responsible for the resulting 90/10 patchwork,” as a Lupa.cz reader put it.
-
21
Always before launch
Two names: who decides what it does, and who answers for the technical side. The author with a few spare hours a week is a risk, not an owner.
-
22
Could a colleague find the code, deploy a small change, replace a key and restore the data without them?
-
23
Tool, hosting, database, domain, AI, email: on the author's private card, the app ends with the first unpaid invoice.
-
24
Run
npm auditor let Dependabot watch it. Flaws turn up even in code nobody has touched for months.
Your ticks are saved only in this browser. We don't send them anywhere.
What does Fabrika handle on its own, and what do we take care of?
Fabrika is a platform your company builds its own apps on, plus our team behind it. What the platform handles applies to every app, whoever wrote it:
| Area | The platform handles | We take care of | Stays with you |
|---|---|---|---|
| Access 01–02 | The platform handles No public address. One entry point lets in only verified users; without access rules, the door stays shut. | We take care of We set it up in your cloud account. | Stays with you Nothing extra. |
| Sign-in and leavers 03–04 | The platform handles One company sign-in for all apps through your identity provider (e.g. Microsoft Entra ID, Google Workspace, Okta). Outside people use a password. | We take care of We connect your identity provider. | Stays with you Company accounts and closing them, including multi-factor settings. |
| Roles 05 | The platform handles Roles per app in one place. A new version won't overwrite them. | We take care of In review we check the app really limits what each role sees. | Stays with you Who gets which role. |
| Data 06–09 | The platform handles In a cloud account in your company's name, usually on Zerops, on AWS on request. | We take care of For Supabase apps we decide with you: move, run Supabase in your account, or leave it. No training on your data. | Stays with you What data belongs in the app. AI runs on your own plan. |
| Backups 10 | The platform handles The platform doesn't back up on its own. | We take care of We set up backups and recovery with you. | Stays with you What, how often, and how fast it has to be back. |
| Keys and passwords 11–13 | The platform handles Held by the cloud provider, not the code. Each app sees only its own; they can be written, never read back. | We take care of On takeover we search the code and repository for keys. | Stays with you Nothing extra. |
| Changes 14–17 | The platform handles Deploys from Git, each one recorded. Separate test and production. A deploy that widens anyone's access waits for a person's approval. | We take care of We review every change before it goes live and report what changed and what we checked. | Stays with you The repository in your company. Which change goes out, and when. |
| Errors and incidents 18–20 | The platform handles Errors from all apps in one place, uptime checks and alerts. Sign-ins and access changes are recorded. | We take care of We help find out what happened, fix it and prepare documents for the report. | Stays with you Filing the report, if you have to. |
| Upkeep 21–24 | The platform handles Code, data and domains stay yours, and the platform is open source. It keeps running without us. | We take care of Operations, change review, platform patches, support for whoever builds. | Stays with you The app's owner. Servers, paid to the cloud provider by usage. |
What we don't vouch for
What a person does with data they're allowed to see. If an employee exports the records and walks off with them, the platform won't stop that.
When doesn't an app belong in company use at all?
- Nobody wants to answer for it. If check 21 ends without a name, switch it off.
- It replaces accounting, payroll or another system with legally prescribed records. Off-the-shelf software is almost always better.
- A ready-made tool does the same thing. Buying is usually cheaper.
- You can't get the code out, as with Bubble, so the app ends with the tool. Fine for a side tool, not for a core process.
- One person uses it and nothing important depends on it. It just mustn't be public or hold sensitive data.
When isn't Fabrika for you?
- A public service for thousands of customers with payments and open sign-up. Fabrika is for apps used by your people and a few outsiders.
- Your IT requires Azure, your own servers or SAML-only sign-in. Fabrika runs apps on Zerops, or on AWS on request, and connects company accounts through OIDC.
- The app lives in Bubble or a similar builder without code export. We can only rebuild it, not take it over.
- You don't want the app in Git. Every change on Fabrika goes through the repository.
- You want the code checked once and will run the app yourselves. A one-off audit is cheaper, though it only covers the version the auditor saw.
What people ask about the checklist
Is it safe to deploy AI-generated code to production?
It can be, but not by default. Sign-in, permissions and keys shouldn't depend on the AI-written code but on the platform it runs on, and someone should read changes before they go live.
I'm not a programmer. Can I run these checks myself?
Most of them, yes. The checks in the code (keys in the repository, RLS rules, permissions on the server) need a developer, so send them the list.
How many checks must pass before colleagues start using the app?
The nine marked “Always before launch”. The rest you can finish along the way, as long as you know what's missing.
Our app runs on the tool's public address. Is that a problem?
If it opens without signing in, yes (checks 01 and 02). On Fabrika the app has no public address at all. How that works for Lovable apps.
Does this have to do with NIS2?
If you fall under the Czech Cyber Security Act (No. 264/2025 Coll.), even the lower regime requires security rules for development and maintenance, and supplier contracts covering change management, an exit strategy and secure development (Decree 410/2025 Coll., Section 3 and Annex 2). Apps your people build count as development. The checklist helps, but it's not legal advice; more in For leadership.
Who will look after the app when its author leaves?
Whoever you name in check 21. If there's nobody, that's the work we do on Fabrika: the code stays in your repository, we handle operations and change review, and a colleague, a developer or we can carry on. What to sort out before they leave.
Should I send the checklist to our IT?
Yes, it's written for them too. Send the link or print it; the ticks stay in your browser, so it opens empty for them. IT's other questions are answered on Security.
Show us your app.
Half an hour and a link to the app or the repository. We'll go through the checklist with you and say what a takeover onto Fabrika would involve, or that it doesn't make sense.