You vibe coded an app. Now what?

The prototype wall

There is a point almost every AI-built app reaches. The demo works. You have shown it to friends, maybe posted it, maybe collected a waitlist. Then one of these happens:

• You ask for a small change and something that worked yesterday stops working. You ask the tool to fix it and it breaks a third thing.
• Someone tells you your database is open, or you read a thread about exposed API keys, and you realise you have no idea whether yours are.
• You try to charge money and discover Stripe is still in test mode, or the webhook never fires, or people get charged and see nothing.
• You want it on the App Store and find out that a Lovable, Bolt, or Base44 project is a website, and Apple has opinions about websites.
• You have burned through two months of credits going in circles, and you are now afraid to touch it.

We call this the prototype wall. It is not a sign that you did something wrong. It is the shape of the tools. Lovable, Bolt, Base44, v0, and Replit are optimised, brilliantly, for the first 80 percent: get an idea on the screen, working, fast. The remaining 20 percent is a different discipline. It has almost nothing to do with the product and everything to do with what happens when strangers, money, and time hit the code.

The underlying feeling was put well by someone in r/lovable this month, in a thread asking whether a non-developer can build a real, secure SaaS at all:

The problem is that even if AI can build it, how would you know if something is secure if you don't understand how it all works under the hood at the code level? I guess you could ask AI to explain it to you but how can you be sure?

r/lovable, August 2026 (thread)

Most people at the wall are not asking "how do I write better prompts." They are asking a much more practical question: who do I go to now, and what will it cost me? That is the question this article answers.

What "production" actually means: the five gates

"Production ready" gets thrown around as if it were a vibe. It is not. When we audit an AI-built app, we are checking whether it clears five specific gates. If you understand these, you can judge any freelancer, agency, or tool by whether they address all five or just one.

Gate 1: Secrets and access

The single most common problem in AI-built apps, and the most expensive one, is that things which should be private are not.

Two versions of it show up over and over. First, API keys living in the front-end code, where anyone who opens the browser's developer tools can read them. That includes OpenAI keys, Stripe secret keys, and service-role database keys. A leaked OpenAI key becomes someone else's free compute until you notice the bill. Second, database tables with no access rules. Supabase, which most Lovable and Bolt projects sit on, protects tables with Row Level Security. When RLS is off, or a policy is written wrong, any user (or anyone with the public key, which is everyone) can read and often write every row in the table. Not just their own. Everyone's.

This is not theoretical, and it is not rare. In May 2025 a researcher's CVE filing reported that of 1,645 Lovable-built apps scanned, 170 were exposing user data (emails, addresses, payment details) through missing or permissive Row Level Security (the disclosure, Semafor's report). In October 2025 a security vendor scanned 5,600 publicly deployed vibe-coded apps across Lovable, Bolt, Base44 and others and found more than 400 leaked secrets and 175 personal-data exposures reachable from public endpoints (Escape's methodology). In early 2026 the AI social network Moltbook, whose founder said he "didn't write a single line of code," exposed 1.5 million API tokens through a Supabase database with no RLS (Wiz's write-up). And a month later a researcher found a Lovable-hosted education app with roughly 18,700 user records open because an authentication check was written backwards, blocking the people it should allow and allowing the people it should block (The Register).

The subtle version is worse than the obvious one. RLS can be switched on and still be useless if the policy says everyone may read everything. One builder who checked his own app put it exactly:

RLS is on, but the policies allow SELECT for everyone. The shield icon shows green, the emails say you're fine, and the data is still wide open.

r/lovable, February 2026 (thread)

Passing this gate means: no secret ever leaves the server, every table has a policy that has actually been tested from the point of view of the wrong user, and the keys that were exposed during prototyping have been rotated, because "exposed once" means "assume copied."

Gate 2: Money

If your app charges people, four things have to be true. Stripe (or RevenueCat, or Apple's in-app purchase system) has to be in live mode with live keys, and those keys have to be on the server. The webhook that tells your app "this person paid" has to be wired, verified, and retried if it fails, because payment confirmation over a webhook is the thing AI builders most often stub and forget. Subscription state has to be stored somewhere your app can trust, so a user who paid still has access next week, and a user who cancelled does not. And receipts, refunds, and failed renewals need to be handled without you doing it by hand.

Get any of these wrong and you either lose money or, worse, take money and deliver nothing, which is how you get chargebacks and one-star reviews on day one.

Gate 3: Failure

Prototypes are demonstrated on the happy path. Production is the unhappy path. What happens when a user pastes an emoji into a field, uploads a 40MB image, loses their connection mid-save, or hits the button twice? In an AI-built app the honest answer is usually "it crashes silently and nobody knows."

The two failure stories that get told most in this world are both Gate 3 stories. In July 2025 an AI coding agent deleted a live production database for SaaStr's Jason Lemkin despite an explicit instruction not to change anything, then told him a rollback was impossible (it was not); Replit's CEO called it "unacceptable" and shipped automatic separation of development and production databases in response (Fortune). The smaller, more common one is the builder who published, saw "publish completed," and found the live site was a black screen because an environment variable that existed in preview did not exist in production (r/lovable). Neither is exotic. Both are what happens when there is no staging, no monitoring, and no backup anyone has tested.

Passing this gate means errors are caught and reported somewhere you will see them, there is monitoring that tells you the app is down before a user does, there are backups you have actually restored once, and there is a staging environment so a change can be tried without being tried on customers.

Gate 4: The store

If you want to be on the App Store or Google Play, your web prototype has to become an app, and the store has to accept it. That is two separate problems.

Turning a web app into a native one has three real paths: wrap it (Capacitor is the standard tool for a Lovable or Bolt project), rebuild the front-end natively, or ship a Progressive Web App and skip the stores entirely. Wrapping is fastest but Apple's guideline 4.2, Minimum Functionality, is explicit that an app should offer something beyond a repackaged website, so a bare wrapper gets rejected. Then there is guideline 3.1.1: digital goods sold inside an iOS app go through Apple's in-app purchase system, not your Stripe checkout, which changes your payments code and your margins. If you offer Google or another third-party sign-in, guideline 4.8 requires an equivalent privacy-preserving option as well, and Sign in with Apple is the standard way to satisfy it. Add the privacy questionnaire, a privacy policy URL that actually describes what you collect, a demo account for the reviewer, and screenshots at the right sizes.

Here is what one builder who got a Lovable app through App Review after three rejections wrote about where it actually got stopped:

The big one is 4.2 (minimum functionality): if the app is essentially your website in a shell, Apple rejects it. I got rejected under 5.1.1 for exactly that. The other two that bit me had nothing to do with AI: a private API a dependency was quietly calling (2.5.1), and a pricing screenshot mismatch (2.3.7). Budget for a couple of rounds regardless.

r/lovable, July 2026 (thread)

Google Play has its own gate that catches nearly every solo builder: personal developer accounts created after November 13, 2023 must run a closed test with at least 12 testers opted in continuously for 14 days before Google will grant production access. That is a calendar constraint, not a code one, and it needs planning.

Gate 5: Change

This is the gate people forget, and it is the one that decides whether you have a business or a fragile artefact. After launch you will still want to change the app. Every change is a chance to break what works. Passing this gate means there are tests that run before a release, a review step where a person reads what changed, a way to roll out to a few users first, and a way to roll back in minutes when something goes wrong.

Without this, the wall does not go away after launch. It just moves to a place where breaking things has a cost. Builders feel this coming even before they launch:

I'm just wondering when I get the developer to migrate it I'm going to then get stuck on making any future changes.

r/lovable, July 2026 (thread)

That worry is correct, and it is the reason a one-time fix is not the same thing as a way forward.

How bad is it? The twenty-minute self audit

You do not need to be technical to get a rough answer. Do these in order.

1. Look for live keys in the front-end. In your project's code, search for sk_live, sk_test, service_role, OPENAI_API_KEY, and SUPABASE_SERVICE. If any of those appear in a file that ships to the browser (anything under src/ in a Lovable or Bolt project, rather than a server function or an environment variable), you have a Gate 1 problem.
2. Check your database rules. In the Supabase dashboard, open each table and look at whether Row Level Security is enabled and what policies exist. A table with RLS off, or with a policy like true for select, is readable by everyone. If you see that on anything with user data, you have a Gate 1 problem.
3. Try to be the wrong user. Sign in as one account, note a record's ID, sign in as a different account, and try to open or edit that record by changing the URL. If it works, your access rules are not real.
4. Check payment mode. In Stripe, look at whether the keys your app uses are test or live, and open Developers, then Webhooks, and check whether your endpoint has ever received an event successfully. No successful events means Gate 2 is open.
5. Break it on purpose. Turn off your wifi mid-action. Paste a paragraph into a number field. Submit a form twice. Then ask: where would I have found out that this happened, if a user did it? If the answer is "nowhere," that is Gate 3.
6. Ask where staging is. If every change goes straight to the URL your users see, there is no staging. Gate 3 and Gate 5.
7. Read Apple's guidelines 4.2 and 3.1.1 if you want to be on the App Store, and ask whether your app clears them today.

Count the open gates. One or two is a normal, fixable prototype. Four or five is also normal, and also fixable, but it tells you that "a few tweaks" is not what you are looking at, and it changes which kind of help makes sense.

Your four ways out, and the half each one is missing

When people hit the wall, they reach for one of four things. Each one solves half the problem, and the half it misses is predictable.

1. Keep prompting

The default move is to keep asking the tool. It sometimes works. It works less and less as the codebase grows, because the tool is generating each fix without a stable understanding of the whole, and every fix has a chance to undo a previous one. You can tell you are in the loop when the same bug returns for the third time, or when the credit bill has become the largest cost in the project.

The people in it describe it the same way, over and over.

As I speak, I am fixing my latest series of bugs when I am supposed to be signing off on 9 months of work. You literally crack open the lid, and nothing but errors and bugs in the code come flying out. It's relentless and never-ending. (And extremely costly)

r/lovable, July 2026 (thread)

shipped my first production app with lovable this month and this gap is very real. the demo worked after a week, making it actually shippable took ~800 edits over a few months. the stuff that bit me never showed up in preview: the AI inventing database columns that didn't exist, android buttons hiding under the gesture bar, and payments that only broke once real license testing on google play started.

r/lovable, July 2026 (same thread)

I asked the agent to fix it. It spun. It wrote code. It fixed old mistakes but made new ones. And then I hit the wall. "You have run out of credits." I ended up spending ~6X my budget, and my app code was becoming a spaghetti mess.

Indie Hackers, January 2026 (post)

There is a version of this that does work: keep prompting for the product, and get the underlying five gates handled by something that is not the prompt. That is the point the rest of this article builds toward. But prompting alone does not close Gate 1 or Gate 5, because the tool that opened them cannot see them.

2. Hire a freelancer

Upwork, Fiverr, a friend of a friend. This is the most common next step and it is a reasonable one. You get a person who can read the code.

The price is all over the place, and the range itself is information. Cheap "quick fix" gigs on the marketplaces run $50 to $500 and, in the words of one agency that wrote up what it sees, are typically surface-only; meaningful production repairs start around $2,500 and commonly land between $2,500 and $6,000 (Fora Soft's 2026 guide). An independent consultant's published rate card for "vibe code cleanup" puts solo work at $1,500 to $3,000 for a small codebase, rising to $4,000 to $8,000 or more for a large one, with a standalone audit at $300 to $800 (Kashif Aziz). Lovable's own partner directory lists shops at $50 to $130 an hour, most with monthly minimums of $1,000 to $4,500 (lovable.dev/experts). And in the r/lovable thread titled "How much to hire a dev?", one developer's answer was blunt: "I charge double to fix these abominations" (thread).

What you usually do not get is a process. A freelancer's job ends when the ticket closes. There is nobody watching uptime at 3am, nobody reviewing the next change you make in Lovable, and nobody accountable when the thing they fixed in March breaks in June. Handoffs are the second problem: the freelancer who understands your app moves on, and the next one starts from zero. And quality is a lottery you are not equipped to judge, which is the whole reason you are hiring.

If you go this way, hire for an audit first, not for "finish my app." Ask for a written list of what is wrong, ordered by risk. That is a deliverable you can evaluate, and it tells you what the real job is before you commit to it.

3. Hire an agency, or a "DevOps" shop

Agencies bring process. Someone owns infrastructure, someone owns QA, and there is usually a real review step. This is the mature answer for a funded company.

The problem is that agencies are priced for funded companies. Retainers start in the thousands per month and are usually quoted per project after a discovery phase, so the first thing you get is not a fix but a meeting about scoping. For an app that has twelve users and is not yet charging, that is the wrong size of solution. You also do not need most of what a DevOps practice does. You need five specific gates closed and someone to keep them closed.

4. Run an AI audit tool

There are now scanners, including Lovable's own security scan, that will read your project and produce a list: exposed key here, RLS missing there. They are useful and you should run one. Lovable's basic scan runs automatically before you publish, and a deeper scan is available on demand; the documentation is clear that "you are responsible for ensuring that your app meets the security requirements appropriate for its use case" (Lovable docs). The researcher behind the 2025 CVE noted that the scanner, at least at launch, checked whether RLS existed rather than whether the policy was correct, which is exactly the "green shield, open data" case above. Third-party scanners such as Vibe App Scanner, Heimdall Scan, and Aikido go further, and some have free tiers.

What a scanner gives you is a list. What it does not give you is a fix, a judgement about which items actually matter for your app, or anyone to ask when the fix does not work. A nontechnical founder holding a list of forty findings is often more stuck than before, because now every item is a new prompting loop. And scanners are quiet on Gates 2, 4, and 5 entirely: they do not know whether your webhook fires, they will not get you through App Review, and they are not there for the next release.

The gap in the middle

Line those four up and the shape is obvious. Prompting gives you speed with no accountability. Freelancers give you a person with no process. Agencies give you a process with no product price. Tools give you a list with no hands.

What almost nobody offers is the middle: a fixed monthly price like a product, real engineers who read your code and fix it like professionals, and accountability that continues after launch. That is the thing we built, and it is worth being clear-eyed about why it did not exist before. Until recently there were not enough nontechnical people with working prototypes to make it a business. Now there are.

Here is how the four options compare on the questions that actually matter at the wall.

What it should cost

Numbers, because "it depends" is not helpful when you are trying to decide.

A freelancer for a genuine production repair: plan on $2,500 to $6,000 for one pass, more if the backend needs rebuilding, plus whatever the next fix costs when it is needed. A "vibe code cleanup" agency: $8,000 to $20,000 and up per engagement, quoted after discovery, according to the same published rate cards cited above. A standalone human audit: anywhere from about $130 (one builder on r/lovable reported paying that for a four-part audit with a walkthrough call, thread) to $800. An automated scanner: free to about $30 a month. Continued prompting: whatever your credit plan costs, multiplied by however long the loop lasts; the Indie Hackers founder above landed at six times budget.

None of those numbers include the thing you actually want, which is someone still there in month three when the App Store rejects an update or Stripe changes an API.

Our pricing is public, which is part of the point. Builder is $50 a month: you keep building it yourself and get launch-readiness audits, fix-it-yourself guides for every finding, and hosting and deploy set up properly. Launch is $500 a month: our team quality checks every release before it ships, you get the operations dashboard, live support for two features a month, and App Store and Play Store submission handled. Scale is $2,000 a month for when the app is the business and downtime costs money: a dedicated engineering and design team, new features built rather than just fixed, and priority incident response. All of it month to month, and the code stays in your repo on your accounts whether you stay or go.

The audit itself is free and comes back in a few days. If the honest answer is that your prototype needs one afternoon of fixes and no ongoing help, the audit will say so.

Getting a web prototype into the App Store

Because this is the question we get asked most, here is the specific version. It is also the point where builders most often give up and pay someone: "I am always able to create production ready web apps, however going to the app store is my biggest point of friction, and with my first app, I ended up having to hire someone to do it for me" (r/lovable).

Decide whether you need the store at all. If your users are on desktop, or your product is a tool people open in a browser, a well-built PWA with a home-screen install skips Apple's fee, Apple's review, and Apple's 15 to 30 percent. Many prototypes should stop here.

If you do need it, wrap first. Capacitor takes your existing web app and produces real iOS and Android projects around it. Your Lovable or Bolt code stays the product. This is the path that respects the work you have already done.

Then earn your place past guideline 4.2. A wrapper on its own is "a repackaged website" in Apple's words. Push notifications, offline behaviour, native share, camera or photo access, and a home screen that behaves like an app all count. You do not need all of them. You need enough that a reviewer opening the app does not feel they are looking at Safari.

Move digital purchases to in-app purchase. If you sell subscriptions or digital goods inside the iOS app, guideline 3.1.1 requires Apple's system. In practice that means RevenueCat or StoreKit alongside your existing Stripe for web, and a single source of truth for who is subscribed. Physical goods and services consumed outside the app can keep using your own checkout.

Prepare the review kit. A test account with data in it, review notes that explain any feature the reviewer might not understand, a privacy policy that matches the privacy questionnaire, and screenshots for every required device size. First submissions get rejected on paperwork far more often than on code.

On Android, start the clock. If your Play Console account is a personal one created after November 2023, you need 12 testers opted in for 14 continuous days before you can publish. Recruit them on day one, not the day you are ready.

Expect a first submission to take a week or two from "the app is done" to "approved," and expect one rejection. It is a process, not a verdict.

If you decide to do it yourself

You might. Some prototypes are small enough, and some founders are motivated enough, that the right move is to close the gates by hand. If that is you:

• Work through the gates in order. Secrets and access first, always, because that is the one with legal and financial exposure.
• Move every secret to a server function or an environment variable your host injects, then rotate the keys you moved.
• Turn on RLS for every table and write policies that reference the signed-in user. Test each one as the wrong user before you believe it.
• Put Stripe in live mode only after the webhook has received and processed a real test event end to end.
• Add error reporting (Sentry has a free tier), uptime monitoring, and a scheduled backup you have restored once.
• Create a staging copy of the app and the database, and stop making changes directly on the live URL.
• Before any change ships, read the diff. If you cannot read it, that is your signal that this is where you need a person.

Our production readiness checklist is the longer version of this list, free, and it is the same one we run.

What working with a team should look like

If you decide you want help, here is what a good version of that looks like, so you can hold anyone (including us) to it.

It starts with an audit, not a sales call. You send the repo or the project link, someone reads all of it, and you get back a written list: what is exposed, what will break, what it will take, in that order. It comes back in days, not weeks.

Then the fixes happen on your code, in your repo. Nobody rebuilds your app from scratch. The product is the part you got right; what changes is what sits under it. Most AI-built apps go from audit to production-ready in two to four weeks, longer if the backend has to be rebuilt properly.

Then someone is watching. Payments, uptime, crashes, and churn on one screen, with a person behind it who notices at 3am so you do not find out from a review.

Then you keep changing it, in Lovable or Cursor or whatever you like, and every change goes through the same tests and the same human review theirs do. Which is the whole point: you keep the speed that got you here, without the gambling.

And at every stage, the code is yours. If you leave, nothing follows you out the door.

Questions people at the wall ask

Is my Lovable app secure?

By default, you should assume not, and check. The two things to look at first are whether any API keys ship to the browser and whether every Supabase table has Row Level Security turned on with a policy that references the signed-in user. Run Lovable's own security scan, then run the twenty-minute self audit above. If either finds anything on a table with user data, treat it as urgent.

Can I publish a Lovable, Bolt, or Base44 app to the App Store?

Yes, but not as-is. The project is a web app; it has to be wrapped (Capacitor is the standard route) and then given enough native behaviour to clear Apple's minimum functionality guideline. If it sells subscriptions, in-app purchase has to be added. Plan on one to two weeks for the store process itself, on top of getting the app production-ready.

How much does it cost to hire someone to fix a vibe coded app?

For a real production repair by a freelancer, published guides put it at roughly $2,500 to $6,000 for one pass; agencies quote $8,000 to $20,000 and up; a standalone human audit runs from about $130 to $800. Our audit is free; ongoing help is $50, $500, or $2,000 a month depending on how much of the operating burden you want carried, and every plan is month to month.

Should I just rebuild it from scratch?

Almost never. The prototype is the expensive part: it encodes what you learned about the product. What is usually wrong is underneath it, and that can be fixed in place. Rebuilding is the right call only when the app was generated on a stack that cannot be secured or scaled, which is rare with the mainstream builders.

Do I have to move off Lovable or Supabase?

No. Supabase in particular is a perfectly good production database when its access rules are written properly. Lovable, Bolt, and Cursor remain fine ways to build features. What changes is what sits around them: where secrets live, what runs before a release, and who is watching.

Can I keep vibe coding after it is in production?

Yes, and you should. The right setup lets you keep building the way you have been, with your changes going through tests and a review before users see them. Speed with a safety net, rather than speed instead of one.

What if my prototype is embarrassing?

Most of them are, and that is the normal starting point, not something to fix before asking for help. The audit tells you exactly how bad it is before you commit to anything.