From AI Prototype to Production: What to Fix Before You Launch
Your AI-built app looks ready. Is it? Here is what to fix before real users, real data, and real money arrive.
G
Georgiana Nutas
·9 min read
You built something in a weekend. Lovable, Bolt, or v0 turned a prompt into a working interface, with login, a dashboard, and a database behind it. It looks ready, and that is the problem.
Moving from AI prototype to production isn't a polish step. A prototype proves an idea works for one person on a good day. A production app has to work for strangers, with their data and their money, on their worst day. AI builders optimize for the first goal. They rarely cover the second.
AI tools generate code that satisfies the prompt you wrote. They do not know what you forgot to ask for. Nobody told the model about the user who pastes a 5 MB string into a form, or two people editing the same record at once. Nobody told it that one customer must never see another customer’s data.
The result is an app that passes the demo and fails in the edge cases. This is no longer anecdotal. In September 2026, UpGuard reported 16,326 Supabase databases with tables readable from the public web, more than half showing signs of personal data (UpGuard). An August 2026 scan of live vibe-coded apps found unauthenticated table reads on 57% of reachable Supabase-backed apps (VibeEval). Supabase’s own production checklist puts Row Level Security first for the same reason.
Most of those failures fall into the categories below, ordered by how much damage they can do.
1. Security: the part you cannot skip
Check your database access rules
If your app runs on Supabase, this is the first thing to review. Row Level Security decides who can read and write which rows. If it is off, or the policies are too broad, any logged-in user (sometimes any visitor) can query data that belongs to someone else.
Tagged:#VibeCoding#WebDevelopment#Supabase
G
Written by
Georgiana Nutas
Building modern web applications at BluDeskSoft. We write about what we learn along the way.
AI-generated apps often ship with RLS disabled, or with a policy permissive enough to let everything through. The app still works, so nothing looks wrong. Check three places, not one: tables, Storage buckets, and Realtime. A public bucket or an unauthorized Realtime channel leaks the same data as an open table. Supabase documents both layers in securing the Data API: grants decide whether a role can touch an object; RLS decides which rows.
Open the project and search for API keys, tokens, and database credentials. Anything in front-end code is public, because the browser has to download it. Privileged keys, such as a Supabase service_role key or a payment secret, must only ever live on the server. If one has been committed or shipped to the client, rotate it. Assume the old key is already in someone else’s logs.
Review authentication and permissions
Test the unhappy paths:
Can a user reach another user’s page by changing the ID in the URL? That is broken object-level authorization, and it has sat at the top of the OWASP API Security Top 10 for a reason.
Is there a real separation between regular users and admins, enforced on the server and not only by hiding buttons?
Do password reset and email verification work end-to-end, including expired and reused links?
Are sessions handled safely when a user logs out, or an account is deleted?
Can someone script signups or password resets until your email provider or database falls over? Rate limits belong on auth routes before launch.
Prototype databases tend to grow by accident. Before launch, check these:
Schema and migrations. Changes should be tracked in versioned migrations, not clicked together in a dashboard you cannot reproduce.
Separate environments. You need at least a development and a production database. Incidents start when you test on live customer data.
Backups you have actually restored. A backup you have never tested is a hope, not a plan. Restore into a scratch project and time it.
Constraints and validation. Required fields, unique values, and sensible limits belong in the database, not only in the form. The form is a hint. The database is the rule.
Storage and files. Avatars, invoices, and uploads need the same access rules as rows. Public-by-default buckets are a common prototype leftover.
If the data model is the part you do not want to own, that is what Supabase development is for: schema first, RLS from the first commit, no lock-in on the database.
3. Performance under real conditions
A prototype with ten rows of test data is always fast. With real data, you see slow queries, missing indexes, and pages that fetch far more than they display.
Check the basics:
Which pages load the most data, and do they paginate?
Are images compressed and sized correctly?
How large is the JavaScript bundle your visitors download?
Do your pages pass the thresholds in Core Web Vitals 2026? Google’s current bar is LCP, INP, and CLS (web.dev).
Slow apps lose users quietly. People do not complain. They leave.
4. SEO and discoverability
Many AI-generated front ends render entirely in the browser. That can make public pages harder for search engines to read and slow to show meaningful content. If the product depends on organic traffic, marketing pages usually need server-side rendering or static generation. The app behind login can stay a client app.
Also check titles, meta descriptions, canonical URLs, a sitemap, and a robots file. Our pre-launch technical SEO checklist covers the fifteen items. LintPage runs the same class of checks automatically if you would rather not do them by hand.
5. Error handling, testing, and monitoring
Prototypes assume everything succeeds. Production does not. A payment fails, an email service times out, or a user loses connection halfway through a form.
Before launch, make sure:
Every important action has a clear success and failure state for the user. No silent spinners.
Log failures somewhere you will actually look. Sentry or an equivalent, with source maps uploaded, is enough.
The critical flows (sign-up, payment, the one thing the product exists to do) have automated tests. Ten tests on the money path beat a hundred on the settings page.
Payment webhooks verify signatures and are idempotent. A retried webhook must not charge or grant access twice.
You get an alert when the app goes down, before a customer emails you.
6. Legal and accessibility basics
If you collect personal data from people in the EU, GDPR applies from day one. That means a clear privacy policy, a lawful basis for processing, a way to export and delete user data, and a deliberate choice about where you store data. Supabase treats this as shared responsibility: they secure the platform; you own processing, consent, and access controls (Supabase GDPR guide). Pick an EU region if residency matters, and sign the processor DPA. We cover the practical side of GDPR compliance for web apps.
Accessibility matters too, and our website accessibility checklist shows what to fix first: keyboard access, labels, contrast, and focus states. Those four catch most of the launch blockers.
7. Can anyone maintain this code?
The last question is the one founders skip. Open the codebase and ask:
Is the structure consistent, or is every feature built a different way?
Is there duplicated logic that will break in three places when you change one?
Could a new developer understand it without the original prompt history?
Do you own the repository, the database, the hosting, the domain, and the billing accounts? “The agency has the login” is not ownership. Our note on post-launch website ownership lists the controls worth confirming before you pay the last invoice.
AI-generated code can be perfectly serviceable. If nobody understands it, every change gets slower and riskier. See the website maintenance checklist for what ongoing care looks like, and maintenance services if you want that owned after launch.
Fix it or rebuild it?
Most prototypes should be hardened, not thrown away. The interface and the validated idea have real value. The usual decision looks like this:
Harden it when the data model is sound, the structure is consistent, and the issues are mostly security, performance, and testing.
Rebuild the foundation when the schema is tangled, the logic is duplicated everywhere, or the architecture cannot support what you plan to add. Keep the design and the learnings.
Rebuild fully only when the prototype cannot be trusted with real data and the cost of fixing it exceeds the cost of starting properly.
Can I launch an app built with Lovable, Bolt, or v0 as is?
For a private demo or a small test group with no sensitive data, often yes. For public users, personal data, or payments, review security and data access first. The scan data above is why.
How long does it take to make an AI prototype production-ready?
It depends on the app's size and the state of the code. A focused audit quickly identifies the real scope, and hardening a well-structured prototype is far faster than a full rebuild.
Is Supabase safe for production?
Yes, when configured correctly. The platform is capable. The security depends on your RLS policies, key handling, and environment setup. Supabase’s production checklist is the vendor’s own version of this article.
Have a prototype that needs to go live?
At BluDeskSoft, we take AI-built prototypes and prepare them for real users: security review, Supabase hardening, performance, and a clean handover. Book a free strategy call, and we will tell you honestly whether to fix it, rebuild it, or launch it as-is.
Your site can look ready and still be invisible to Google. Find out why.
BluDeskSoft
-800x450.webp)
-800x450.webp)
-2-800x450.webp)