Selling a Vibe-Coded App: The Seller's Prep Plan

Who prepares what

You don't need a team to get ready, but you do need to know who owns each job. A deal can stall because one task had no owner. If you worked with a freelancer, ask them to confirm in writing what they can still access before you start.

• List every account and move it to a company login. Who does it: you, the founder. Why it matters: only you know where everything lives.
• Fix secrets, security rules and payment logic. Who does it: a developer. Why it matters: these are technical fixes, not admin.
• Write a README and test a fresh setup. Who does it: a developer, then someone who has never seen the code. Why it matters: it proves the app runs without you.
• Check the database export and restore. Who does it: a developer. Why it matters: the buyer needs the data, not only the code.
• Check the privacy policy and terms. Who does it: you, with a lawyer if you're unsure. Why it matters: user data has to be transferable.
• Pull revenue and cost reports. Who does it: you. Why it matters: buyers trust source data, not summaries.
• Answer buyer questions. Who does it: you. Why it matters: the buyer is judging you as much as the app.

Step 1: Get every account into the right name

Do this first. Transfers can take a while, and they depend on other people. Anything on a personal email or a freelancer's login moves to a company account now. If you do it in the middle of a deal, it looks like you were hiding something. List everything the app relies on:

• GitHub repository
• The builder project (Lovable, Bolt, Replit) if the app still runs there
• Database and auth (Supabase, Firebase)
• Hosting, domain and DNS
• Apple Developer and Google Play Console
• Stripe, email, analytics and any AI API accounts

Step 2: Fix the known blockers

Vibe-coded apps tend to break in the same three places. Fix them before a buyer's developer finds them. The full list of checks, with the step-by-step version for payments, is in our AI prototype to production articles.

• Secrets. Rotate every API key that was ever committed to the repo, and move all keys into environment variables.
• Data access. Make sure no logged-in user can read another user's records. On Supabase, that means row-level security on every table, tested with a second account.
• Payments. Check that the paid users in your database match the active subscriptions in Stripe, and that refunds and cancellations update both.

Step 3: Prove someone else can run it

Ask a developer who has never touched the project to clone the repo and start it using only your README. Every question they ask shows a gap in your documentation. Fix it, then run the test again. Do the same for the data. Export the full database, restore it somewhere else and confirm the app works on the copy.

Step 4: Check the app store transfer rules

If your app is on the App Store or Google Play, the listing has to move to the buyer's developer account. Both stores allow this, with conditions. Read both official pages before you promise a buyer a smooth handover.

• Apple's app transfer overview says only the Account Holder can start and accept a transfer, and the app has to meet Apple's transfer criteria. Apps with auto-renewable subscriptions need an app-specific shared secret. Apps that use Sign in with Apple need transfer identifiers generated for each user.
• Google's Play Console Help page, Transfer apps to a different developer account, says both Google Play developer accounts need to be registered and active. For paid apps or apps with in-app products, the target account needs an active payments profile. Any Firebase projects have to be unlinked from the original Play Console account and linked to the target account.

Step 5: Put your proof together

Set up read-only access to your payment data (Stripe, App Store Connect, Google Play) and prepare a monthly view of your hosting and AI API costs. For a detailed look at what buyers and investors check, see our investor and fundraising guides. Still unsure whether to sell this app or rebuild it first? Book a call. It's a free 30 minute call.

What to say when the buyer asks

Buyers ask the same questions every time. Write your answers before the first call so you stay calm and give the same answer each time. If you can't give an honest answer to one of these, fix the gap before you go further with the buyer.

• "Was this built with AI?" Say yes, and say what you checked afterwards. "Built with Cursor. We rotated all keys, added row-level security and tested signup and payment by hand." If a buyer finds out on their own, they will trust everything else you say less.
• "Can my developer run it?" "Yes. Here's the README. Someone outside the project set it up from scratch." Only say this if you actually ran the test in Step 3.
• "Is the revenue real?" "Here's read-only access to Stripe." Don't send screenshots. Show refunds and cancellations too, before they ask.
• "What does each user cost to run?" Share the monthly hosting and API bills. If the app depends on one AI provider, say so, and explain what would change if that provider raised its prices.
• "What happens when you leave?" Offer a handover period with a clear end date. Only offer what you can actually deliver.
• "Is anything still on your personal accounts?" If you did Step 1, the answer is no.

When to stop selling and rebuild

Some apps aren't ready to sell. If you push ahead anyway, the price drops or the deal falls apart near the end. Stop and rethink if:

• Fixing one bug keeps breaking something else
• The app can't leave the builder platform
• Signup or payment only works when users follow the expected path
• A buyer's developer recommends a rewrite, and the offer drops to match
• You can't explain how a core feature works

Harden or rebuild

Our AI prototype to production service covers an AI-generated code audit (punch list), a harden vs rebuild recommendation, and fixes to authz, RLS, secrets and payments. You keep the GitHub. If a rebuild makes more sense, our MVP development package is fixed at $3,460 for your app on the web, iOS and Android. It's delivered in about 20 days, with progress shown every week. Design is included, 100% of the code sits on your GitHub, and you get 2 weeks of fixes after launch.

• Harden when the app works, the structure makes sense and the problems are specific: secrets, security rules, missing tests, accounts in the wrong name.
• Rebuild when the list above sounds familiar. The buyer will take the cost of a rebuild off the price anyway. If you rebuild first, you sell a clean app at full value instead of handing the buyer a discount.

Find out if your app needs fixing or rebuilding

Ready to find out whether your app needs fixing or rebuilding before you sell? Book a call. You get a fixed quote before any work starts.

What should I do first when preparing to sell my app?

Move every account into a name you control. This step depends on other people, so it often takes the longest, and every later step relies on it.

Do I need a developer to prepare the sale?

Yes, for secrets, data access, payments and the setup test. The account list, revenue reports and buyer answers are your job.

Can I transfer my app to a buyer's App Store or Google Play account?

Yes. Both stores allow transfers, with conditions. Before you list, read Apple's app transfer overview and Google's Play Console Help page on transferring apps to a different developer account.

Should I rebuild before selling?

Only if fixes keep breaking other features, the app can't leave its builder, or core flows break easily. Otherwise, fix the specific problems and sell what you have.