How to launch a vibe-coded app: what to fix and where

Four checks decide whether launching a vibe-coded app brings you users or leaks your keys. Run them in this order, then launch on sites that take a live app.

To launch a vibe-coded app, put it on your own domain, make sure crawlers and link previews get real HTML with a title on every page, keep secret keys out of the browser and turn on row-level security, walk through signup as a stranger, then launch on sites that accept a live app people can use today.

Deploying gives you a URL. Launching puts that URL in front of strangers, crawlers and the reviewers at each launch site, and each of them checks something a deploy guide skips. Checked November 2026: the platform rules and builder docs quoted below were read on their own pages on 9 November 2026.

Why is deploying not the same as launching?

Most guides written for this search end once the app is live on a host. The sites you would launch on ask for more than a working URL, and each one states its rule plainly.

• BetaList does not accept free hosting subdomains or app store links. You need your own domain.
• Show HN "is for something you've made that other people can play with." Sign-up pages and landing pages are off topic.
• Product Hunt says "A closed beta that nobody can join usually isn't a good fit," and asks makers to test the main flow in production as a new user before launch.
• Peerlist Launchpad takes projects only from verified Peerlist profiles.

Crawlers want something else again: HTML they can read without running your JavaScript, a sitemap, and a different title on each page. An AI builder such as Lovable, Bolt, v0 or Cursor gets you to a working app quickly and leaves most of this list to you.

Step 1: Move the app to your own domain

Lovable's docs tell you to connect your own domain and make it the primary one, so branding, backlinks and canonical URLs consolidate there, with every other connected domain redirecting to it. They describe a lovable.app subdomain as fine for MVPs, demos and internal tools. A launch is none of those, and BetaList's rule settles it if you plan to submit there.

The same reasoning applies on any builder's default subdomain. Once the domain is primary, verify it in Search Console, submit the sitemap, and use Search Console's URL Inspection tool on the home page: it shows the most recently indexed version of a page and can run a live test of the current one. Lovable's docs suggest publishing your latest changes before you submit the sitemap, because Google reads the live site.

Step 2: Check that crawlers get real HTML

What a crawler receives depends on how the app renders. Lovable apps created from 13 May 2026 (22 June 2026 on Enterprise) use TanStack Start with server-side rendering, and Lovable says "Every request returns fully rendered HTML, for humans and crawlers." Older React and Vite apps are pre-rendered on request, but only for verified crawlers: search engines such as Google and Bing, AI search crawlers, social-preview bots and verified SEO tools. Any other bot gets the single-page app.

Do not take the builder's word for your own app. Fetch two different routes and compare what comes back:

curl -s https://yourapp.com/ | grep -io "<title>[^<]*"
curl -s https://yourapp.com/pricing | grep -io "<title>[^<]*"

If both print the same title, or the page's text is missing from the response, crawlers that do not run JavaScript see an empty shell. Then check /sitemap.xml: Lovable's docs say it does not always create one, and the file should be valid XML with absolute URLs on your own host and no placeholder routes. Give each important page its own title and description, and make sure the canonical tags do not all point at the home page.

The fixes for each builder are in the guide to vibe-coded apps that are not indexed, and Lovable's two rendering setups are covered in the Lovable SEO guide.

Step 3: Fix the link preview before you post the link

Every launch post, chat message and social share shows a preview card, and a broken one is the first thing a visitor sees. The Open Graph protocol requires four properties on every page: og:title, og:type, og:image and og:url, the last being the canonical URL used as the page's permanent ID. Lovable's docs add a unique og:description per route and share images around 1200 by 630 pixels, kept to a few hundred KB.

Test the card where you will post it. Paste the URL into a private message to yourself on the platform you plan to use and look at the title and image before launch day. If the image is missing, the guide to OG images that are not showing walks through the usual causes in order.

Step 4: Keep secrets out of the browser and lock the database

Vibe-coded apps often call third-party APIs straight from the front end, which puts the key in the code every visitor downloads. Vite's docs say "Variables prefixed with VITE_ will be exposed in client-side source code after Vite bundling," and that those variables must not contain sensitive information such as API keys. A secret key belongs in a backend, a serverless function or an edge function. To check, open your deployed site's JavaScript in the browser's developer tools and search for the first few characters of each secret you have set.

If the app uses Supabase, row-level security is the second check. Supabase's docs say "Enable RLS on every table in an exposed schema," and warn that a table in an exposed schema without RLS "is readable and writable by any role with a grant on it." With RLS on and no policies, the publishable key reads nothing until you add policies, which is the safe starting point. The vibe-coded app security checklist gives a one-line test for each of these and for exposed files and headers.

Step 5: Walk the first run as a stranger

Open a private window and go through the app as someone who has never seen it. Sign up with an email you have not used, confirm it, and reach the first screen that does something useful. If there is a paywall, pay in your payment provider's test mode. Sign out and back in. Then open the exact page your launch post will link to, on a phone.

Write down every place you hesitated. Product Hunt's featuring guidance asks for clarity ("plain language that's easy to grasp on first read") and for a main flow tested in production by a new user, and Show HN readers will try the demo within minutes of your post. A waitlist with no way in fails both: Product Hunt does not see a closed beta as a good fit, and Show HN wants something people can use.

Where should you launch a vibe-coded app?

Choose sites that take a live product someone can use today, and match the audience to what you built. The table lists the terms that matter most for an app made with an AI builder.

For a wider list with every price and link term, see the LaunchScaler alternatives, checked the same day.

What happened to Lovable Launched?

Lovable's own 2025 guide to launching a Lovable app recommends Lovable Launched, "a platform, similar to Product Hunt," where people "can discover and vote on" apps, and says "It's free." When checked on 9 November 2026, launched.lovable.dev returned a permanent redirect to the lovable.dev homepage. Check it again before you build a launch day around it, and treat Product Hunt, which the same guide also recommends, as the main option.

In what order should the launch run?

Do the fixes first and the launches last, and give each launch its own day. Both Product Hunt ("Never ask for upvotes") and Show HN ("Please don't ask friends to upvote or comment") reward being there to answer people, which you cannot do on three sites at once.

1. Two weeks before: own domain live and primary, Search Console verified, sitemap submitted.
2. The same week: run the crawler, preview, secrets and row-level security checks from steps 2 to 4, and fix what fails.
3. One week before: walk the first run as a stranger, on desktop and phone, and fix what slowed you down.
4. Launch day: one main site. Product Hunt for a general product, scheduled from tomorrow up to 30 days ahead; Show HN for a technical product with a demo. Stay online and reply to every comment.
5. The following days: the smaller boards, each on its own day, so each gets your attention.
6. Afterwards: read signups by source, fix the most common complaint, and write pages that answer the questions people asked on launch day. If writing those pages is what stalls, LaunchScaler's content engine plans them from your own Search Console queries and writes one a day, at $99/mo per website.

Run the free scan before launch day

LaunchScaler's free scan runs 156 checks across 6 of its 7 categories against the URL you give it, with no account: whether crawlers can read your pages, titles and link previews, security headers and exposed files, speed, and whether forms and flows work. It covers the crawler, preview, header and working-flow checks above in one pass. It does not read your database, so row-level security stays on your own list. Run the free scan on your domain before you book a launch day.