Vibe Code to Production: Finish Your AI-Built App

It depends on who wrote the code. If you built the app yourself, in any tool including Cursor or Claude Code, start with no-code to production. If a developer or agency wrote it, with or without AI tools, App Rescue is the right service. Both start with a free check, so if you're not sure, tell us how the app was made and we'll point you to the right one.

It can be, once you've answered a few questions. Who fixes it if it breaks first thing on a Monday? Can each person see only what they should? Is the data backed up, and stored somewhere your company is allowed to keep it? What happens when two people edit the same record? If you can't answer those yet, the free check will tell you what to sort out before rollout, and App Care answers the first question afterwards.

Before paying for more of the same, get someone to write down what's wrong. A £95 review gives you that in writing, whoever does the work next. Before anyone else touches the app, make sure the code is in a repository you own and every account is in your name.

Check the basics first: is the app public, is it on your own domain with the right canonical address, and is it in Google Search Console? If all that's fine, rendering is the usual cause. Many AI-built web apps send an almost empty HTML page and fill it in with JavaScript. Google can render that, though often later, but in Vercel's December 2024 analysis none of the major AI crawlers rendered JavaScript. Some hosts pre-render pages for crawlers: Lovable does this for apps it hosts, which also means moving off Lovable's hosting loses it. Anywhere else, the fix is to send real HTML through server rendering or pre-rendering.

Yes, with an extra step. Registering costs a one-off US$25. Google Play then requires personal developer accounts created after 13 November 2023 to run a closed test with at least 12 testers who stay opted in for 14 days in a row before the app can go to production. Plan for that fortnight in your launch date.

Most AI builders charge in credits, and costs grow in two places. While you build, credits go every time a prompt fixes one thing and breaks another. After launch, database and hosting usage grows with real users. Founders have also posted about usage bills that ran on without a warning email, and about spending limits they thought were set but weren't. Once customers are paying you, it's worth running the app on infrastructure where you can see and cap each cost.

The free check is a written reply from a person, based on a short form about your app: what we'd look at first, and whether we think you need us. The £95 review is an engineer's look at what automated scans can't judge. Can you charge for your app on the web and in the stores? Are your business rules enforced in code? Can search engines and AI assistants find your pages? What do you own, and what are you tied to? You get the findings in writing, with a fixed quote if there's work to do, and the £95 is credited in full against any paid work we do next.

Usually not. Apple's App Manager role can submit apps for review, and can upload builds once you give it access to certificates, identifiers and profiles, which covers what a developer needs to publish your app. Admins can add and remove users, and only the Account Holder can accept Apple's legal agreements, so keep both roles for yourself. If someone asks for Admin just to submit a build, ask them why. Google Play Console lets you grant permissions app by app, and the same principle applies.

Often, yes. If you can read what the tool changes, your app doesn't take payments or hold sensitive personal data, and you have the time, an AI coding tool is a cheap way to move off a builder, and plenty of founders have done it. It gets harder when you can't judge the output. The tool may tell you a security rule is in place when it isn't, and getting web payments and store subscriptions to agree on one customer can take weeks of prompting. A £95 review still helps if you do the work yourself, because you'll know what to ask the tool for and what to check.

Yes. These questionnaires ask about encryption, access control, backups, incident response and where data is stored, and an app built quickly on an AI builder often can't answer them yet. We fix the architecture first. Then we help with the evidence buyers usually ask for next: a penetration test from a CREST-accredited firm, Cyber Essentials (often required for UK public-sector supply chains), a data processing agreement, and a route to ISO 27001 or SOC 2 as deals get larger.

Often not without a check, and that's no reflection on you. The usual problems are these: a table added after launch with row level security switched off, a secret key in the front end, a payment webhook that doesn't check who sent it, or a business rule that only exists in the AI's prompt. A proper check also asks whether one customer could see another customer's data, and whether your sign-up emails arrive. The free check tells you whether a £95 review is worth it.

After a delivery, the first month of App Care is included and the onboarding fee is waived, so the team that built the app is watching it through launch. App Care has a three-month initial term: months two and three are billed at your plan's rate, from £675 a month, and it's rolling monthly after that. It covers OS and dependency updates, store compliance and crash monitoring, with a shared Slack channel and a named contact. Critical issues, such as the app being down or users unable to log in, get a 2-hour response during UK office hours.

You do. The code sits in your GitHub or GitLab organisation from the first commit. Your Apple Developer, Google Play, hosting and database accounts stay in your name, you keep the owner role on each, and we work in them with scoped access, never shared logins. Our contract assigns the IP in our work to you on payment of each milestone, and we'll sign an NDA at the start if you need one. The original project in your AI builder stays yours too, so you can keep using it or edit the new code with an AI tool yourself.

It can, but watch the costs. Bubble charges by workload units, and a native app tends to call the API more often than a web page does, through background refreshes and polling, so usage can climb after launch. For most projects we'd leave Bubble's working workflows where they are and move the busiest endpoints, such as sign-in, lists and search, onto Supabase or Firebase as part of the native build. Bubble exports no code, so the front end itself is always a rebuild.

Some keys are meant to be public. A Supabase anon key or a Stripe publishable key sits in the browser by design, and it's only safe while the rules behind it are right, such as row level security on every database table. Secret keys are the ones that must never reach the browser: a Stripe secret key, an OpenAI key or a Supabase service role key. AI-generated code sometimes puts those in the front end, and wrapping the app for the stores doesn't hide them, because the JavaScript ships inside the app. We move secret keys, and the logic that uses them, into server-side functions.

Yes, from your own developer accounts. We always publish from the founder's Apple and Google accounts, and you keep the owner role on both. Apple's Guideline 5.2.1 says apps "should be submitted by the person or legal entity that owns or has licensed the intellectual property", and that's you. We set up App Store Connect and the Play Console, prepare screenshots, privacy details, age ratings and subscription products, upload builds, and handle reviewer questions and resubmissions. Our first-submission approval rate is 90%. On Apple, an App Manager role can submit for review without Admin rights, and can upload builds once you give it access to certificates, identifiers and profiles.

The first check is free. The review is £95, credited in full against any paid work we do next. Getting your existing app to production is a fixed £999 to £1,999 depending on complexity, agreed before any work starts: fixes, security, moving your backend, in-app payments, store submission, or a wrapper route to the stores. A full native or cross-platform rebuild isn't in that band, and we give you a fixed-price quote for it after the review. After a delivery, the first month of App Care's three-month initial term is included and the onboarding fee is waived. Months two and three are billed at your plan's rate, from £675 a month.

If you're coming from FlutterFlow, choose Flutter, because your existing code carries forward. If your app is built in React (Lovable, Base44 and Bolt.new all are), React Native with Expo lets you share business logic, hooks and TypeScript types between your web app and your mobile app. Replit's mobile apps are already React Native. If you're starting fresh, both are proven in production and we build in both, so the choice comes down to your team and your roadmap. The review includes a specific recommendation for your app.

It depends on what the review finds. Tightening security rules and moving to hosting you own is usually the quickest part. Adding in-app purchases across the web and both stores takes longer. A full native rebuild with new features sits outside the fixed band and typically runs 10 to 20 weeks to App Store release. Store review time comes on top, and so do Google Play's 14 days of closed testing if you publish from a personal developer account created after 13 November 2023. You'll get a timeline for your own project with the review.

A wrapper built with a tool such as Capacitor is fine for plenty of apps. Wrapped apps built on Lovable, Base44 and other builders are live in both stores, and we'll tell you if yours can go that way. We recommend a rebuild in React Native with Expo, or in Flutter, when the wrapper keeps getting in the way: payments that have to work across the web and both stores, offline use, background tasks, or device features it can't reach cleanly. On Apple, a wrapper still has to meet Guideline 4.2, which asks for more than "a repackaged website". In the first-hand accounts we read from founders who submitted AI-built apps in 2026, that was a rare reason for rejection, and subscriptions, sign-in and iPad layouts were far more common ones. Google Play's webview rule is aimed at sites the developer doesn't own, but its minimum functionality policy applies to every app.

Your users keep their accounts and their data. If your backend is already one you control, such as your own Supabase or Firebase project, the new app connects to it directly. If the data sits inside the builder, we export it, rebuild the database structure in an account you own, and plan the switch so nobody gets locked out. Passwords don't always survive a move between systems, so we test that early and only ask users to reset them if there's no other way.

Yes. FlutterFlow exports a real Flutter project, with its own helper code copied into a lib/flutter_flow folder. Once you edit that export there's no way back into the FlutterFlow editor, so treat the move as one way. We audit the generated code, replace FlutterFlow-specific widgets where they get in the way, move state management to BLoC or Riverpod, and set up release builds for the App Store and Google Play. It's often much faster than starting from nothing, because the screens and the Firebase or Supabase connection already exist.

Not always. If your app is simple, you aren't charging inside the app stores, and the platform's costs and limits suit you, staying put can be the right call, and we'll say so. It's usually time to move when you need in-app purchases on iPhone or Android, when your monthly bill grows faster than your users, when every change breaks another part of the app, or when customers ask where their data is stored and you can't answer. The free check is a quick way to find out which side of that line you're on.

Not by default. Your screens, product decisions and users' data usually carry forward. What most often needs replacing is underneath: the backend, sign-in, payments and hosting. Apps from Lovable, Base44 and Bolt.new are built in React, so business logic and API code often move into a React Native or Next.js codebase. FlutterFlow exports real Flutter code we can continue from. Bubble exports no code, so its front end is rebuilt while your data stays where it is behind an API. The £95 review tells you which parts we'd keep before you spend anything on delivery.

Yes. Flutter apps are written in Dart, Google's strictly typed programming language. AI coding assistants such as GitHub Copilot, Cursor and Claude Code can write a lot of it, but someone still has to own the business logic, state management and API integrations, and check what the assistant produced.

FlutterFlow gets you further without writing code, and it exports a real Flutter project. Once your app needs custom behaviour or store-ready release builds, that project needs a developer who reads Dart.