App takeover · AI-built apps
Your AI-built app works. Now make it safe for real users.
A vibe coded app can get you to a working demo in a weekend. Taking it to production means checking the parts the generator could not see: who can read your data, which keys shipped to the browser, and what happens when a payment fails.
What changes when real users arrive
Tools like Lovable, Bolt, Replit, Cursor, FlutterFlow and Base44 are good at producing screens and flows that work for the person building them. Real users are different: they sign up with odd emails, open the network tab, share links, cancel subscriptions halfway and install the app on phones you never tested.
Lovable itself is clear about the limits. Its own security scanners, it says, "help identify common security issues, but they cannot guarantee complete security", and the builder remains responsible for meeting the security requirements of the app’s use case. That responsibility is what we take over.
What usually breaks in an AI-built app
Auth that only covers the screens
The login page works, but the API and database behind it accept requests from anyone who holds the public key. Hiding a button is not access control; the rule has to live on the server or in the database.
Supabase tables without Row Level Security
Supabase’s documentation states that a table in an exposed schema without RLS is readable and writable by any role with a grant on it, and tells you to enable RLS on every such table. With RLS on and no policies, nothing is readable through the publishable key until you write the policies.
Secrets shipped in the client
Anything bundled into a web or mobile app can be read by its users. Vite warns that VITE_* variables are bundled into your source code at build time and must not hold API keys. Supabase says a secret key bypasses every RLS policy and must never go into a browser, a shipped app or source control.
Payments that work once
The first checkout succeeds in the demo. In production, webhooks arrive late, twice or out of order, and cards need extra authentication. Stripe does not guarantee event order and tells you to handle duplicate events, so access has to follow the webhook, not the redirect.
Store release
Apple requires in-app account deletion when an app supports account creation, and a working demo account for review. New personal Google Play developer accounts need a closed test with at least 12 testers opted in for 14 days before production access.
No monitoring
When something breaks, the first report comes from a user, if at all. Production needs crash and error tracking, uptime checks and an alert that reaches a person.
Production checklist for a vibe coded app
The list we run through in the audit. You can use it yourself first.
- RLS is enabled on every table in an exposed Supabase schema, and every table has explicit policies.
- Policies are tested as a signed-out user, as a normal user and as a different user trying to read someone else’s rows.
- No secret or service-role key appears in the web bundle, the mobile binary or the git history.
- Only publishable keys and public config sit in client-side environment variables.
- Admin actions and data exports go through a server function that checks the caller’s role.
- Payment webhooks verify the signature, ignore duplicates and grant or revoke access on their own.
- Account deletion is available inside the app and, for Google Play, through a web link.
- Review notes include a demo account, and the backend is running while the build is in review.
- Crash reporting, error tracking and uptime alerts are set up and send to a real person.
- Backups exist, and a restore has been tested at least once.
The rules behind the checklist
Quoted or paraphrased from the official documentation, checked on September 27, 2026.
- Supabase RLS
- A table in an exposed schema without RLS is readable and writable by any role with a grant on it. Enable RLS on every table in an exposed schema. Supabase Docs: Row Level Security
- Client-side env variables
- VITE_* variables are bundled into your source code at build time and should not contain sensitive information such as API keys. Vite: Env variables and modes
- App Store account deletion
- If an app supports account creation, it must also offer account deletion within the app (guideline 5.1.1(v)). Apple: App Review Guidelines
- Google Play account deletion
- Apps that let users create accounts must offer an in-app path to delete the account and data, and a web link for deletion requests. Play Console Help: Understanding Google Play’s app account deletion requirements
- Google Play production access
- New personal developer accounts need a closed test with at least 12 testers opted in continuously for 14 days before applying for production. Play Console Help: App testing requirements for new personal developer accounts
How the takeover works for an AI-built app
Audit
Fixed price, written report in 5 working days. We run the checklist above against your code, database and store accounts and rank each finding by severity.
Production sprint
Fixed price, 2–4 weeks. We keep what works, fix the access rules and keys, wire payments properly, add monitoring and ship the release.
Care
Monthly. Updates, store deadlines, monitoring and a block of hours for the next features.
Questions about AI-built apps
Do I have to leave Lovable, Bolt or FlutterFlow?
Not necessarily. If your app can keep being edited in the tool, we can work alongside it. If the exported code has already moved on, we work in the repository and tell you plainly what that means for future edits in the tool.
Is my Lovable app secure if the security scan passed?
A clean scan is a good sign, not a guarantee; Lovable says so itself. The audit tests your access rules as different users and looks for keys in the shipped code, which a scan may not cover for your specific app.
Will you rewrite it by hand?
Only the parts that need it. Generated code is ordinary code; much of it is fine. The audit report separates what to keep from what to fix.
Can you get it into the App Store and Google Play?
Yes. Store release is part of the sprint: signing, privacy details, account deletion, review notes and the Google Play testing requirement for new accounts.
What do you need from me to start?
Read-only access to the repository, a Viewer or Developer role in the store consoles, and access to the Supabase or database project.
Next step
30 minutes with an engineer, not a sales rep. You leave knowing what we'd fix first — or that you don't need us. Tell us what you built it with; the call is free, and reading your code is the paid audit.
Sources
- Supabase Docs: Row Level Security
- Supabase Docs: Understanding API keys
- Lovable Docs: Security
- Vite: Env variables and modes
- Stripe Docs: Receive Stripe events in your webhook endpoint
- Apple: App Review Guidelines
- Play Console Help: Understanding Google Play’s app account deletion requirements
- Play Console Help: App testing requirements for new personal developer accounts
Checked September 27, 2026.