# Your vibe-coded app works. Is it ready to launch? > The demo proves the frontend and backend. What decides launch sits underneath them, and only some of it is your platform's job. - URL: https://envisageapps.com.au/blog/vibe-coded-app-launch-ready/ - Type: post - Published: 2026-11-15 - Tags: app-development, app-development-australia, artificial-intelligence ## Is my vibe-coded app ready to launch? A vibe-coded app that works in a demo has proved the frontend and backend. Launch depends on what sits underneath and around them. Your platform already handles some of it, such as hosting, TLS and a CDN on Vercel or Netlify. It leaves some to you, such as Supabase row level security, rate limits and backups. Someone outside your team decides the rest: Apple's reviewer, Google Play's testing rule, an Australian regulator or a customer's security review. ## Related questions ### Do I need a CDN and load balancer for my app? Most apps do not need a CDN or load balancer built as separate pieces. A frontend hosted on Vercel, Netlify or Cloudflare is already served from a CDN, and the platform scales it. You still own anything that runs outside that platform. You also own the decisions it cannot make for you: which pages are safe to cache, and which requests should be refused when traffic spikes. ### Can an AI coding tool fix these gaps if I ask it to? An AI coding tool can fix many gaps once someone names them precisely. It cannot tell you which gaps your app has without seeing your build, and it cannot pass the gates other people decide. Apple's reviewer, the TGA and a bank's security team each judge your actual app, not the code you describe in a prompt. ### How long does Google Play's testing requirement take? Google Play's testing requirement takes at least 14 days. For a personal developer account created after 13 November 2023, Google requires a closed test with at least 12 testers opted in for 14 continuous days before you can apply for production access. Organisation accounts are not bound by the same rule. Plan for at least two weeks before an Android launch on a new personal account. A vibe-coded app can sign people up, save their data and deploy on every push without being ready to launch. You built it with Lovable, Bolt, Cursor or Claude, and the demo went well. That proves the frontend and the backend. It says little about what sits underneath them. It says nothing about the people outside your team who decide whether it launches. The usual list of what a prototype is missing runs to about a dozen layers. It covers auth and permissions, hosting, compute, CI/CD, row level security, rate limiting, caching and CDN, scaling, error tracking, database hardening, backups and recovery. The list is fair. Presented flat, it is also misleading, because it suggests you have to build every layer yourself. Sort the layers by who does the work and the picture changes. Then there is a group the list leaves out altogether. ## The platform already handles it If your frontend is on Vercel, Netlify or Cloudflare, you already have a CDN, TLS certificates, automatic scaling for the frontend and a deploy pipeline tied to your Git repository. Supabase and Firebase run, patch and scale the database server for you. Nobody needs to add a load balancer in front of a Vercel app. What you owe these layers is a check that they are switched on for the plan you are paying for, and that you understand where they stop. A platform scales the part it hosts. A background job, a webhook handler or an AI call running somewhere else is outside it. Between the two sits the part of the list where the platform gives you the tool and leaves the decision with you: row level security, permissions, rate limits, secrets and recovery. Most AI-built apps that come unstuck do it here, because the defaults are permissive and nothing in a demo exercises them. ## Someone else decides it The engineering list stops here, and this is the group it leaves out. These gates are not layers you build. Someone outside your team looks at your app and decides. ### Apple's reviewer Guideline 4.2 rejects an app that does nothing the website doesn't, which is the usual fate of a wrapped web app. Guideline 5.1.1(v) requires in-app account deletion if the app lets people create an account. Since November 2025, guideline 5.1.2(i) requires explicit permission before personal data goes to a third-party AI. We cover the first of these in [Guideline 4.2: why Apple says your app isn't app-like](/blog/app-rejected-guideline-4-2/). ### Google Play's testing rule A personal developer account created after 13 November 2023 must run a closed test with at least 12 testers, opted in for 14 continuous days, before it can [apply for production access](https://support.google.com/googleplay/android-developer/answer/14151465). That is two weeks you cannot prompt your way through. ### Australian rules Which ones apply depends on what the app does. A health app may be a medical device in the TGA's eyes, decided on intended use. The Privacy Act makes you answerable for personal data you send overseas, which includes most calls to a hosted model; our post on [data residency for AI-built apps](/blog/data-residency-ai-built-apps/) covers it. From 10 December 2026, an app that uses personal information to make decisions that significantly affect people has to say so in its privacy policy. Age assurance, the Consumer Data Right and WCAG 2.2 AA catch other apps. ### The customer's security review Sell to a bank, a hospital or a large company and their security questionnaire will ask how you control access, where data goes and how AI-generated code was tested. The questions are standard. They are answered from your build, not from what you meant the build to do. ## What to do with this Treat what the platform handles as a checklist to confirm, not build. The configuration in between is harder to judge from the inside. It looks finished until someone outside the team tries to break it. The gates someone else decides are where a prompt stops helping. A coding tool can explain guideline 4.2. It cannot tell you whether your app clears it, because it isn't the reviewer and it hasn't seen your build. The free Envisage Apps [Launch Gate Check](/launch-gate-check/) names those gates for your app, with the guideline number for each and who decides it. No sign-up, and nothing is stored. If you want them tested on your build, the [Launch Gate Audit](/launch-gate-audit/) does that on real devices in five business days, along with auth, access control and secrets, and a senior engineer validates every finding.