Is your vibe-coded app ready for production?

What the checker looks for, and why

AI app builders get you to a working preview fast. The first deploy is where things break: a key that was fine on your laptop is now public, a page refresh shows a 404, or the login email sends people to localhost. The checker looks at your live app from the outside, the way a visitor or an attacker would, and reports on six things.

Reachable over HTTPS

We load your URL over https:// and check it answers with a success code, then ask for the plain http:// address to see whether it sends visitors on to https://. A site that only works over http shows "Not secure" in every browser, and things like logins, geolocation and service workers need HTTPS.

Browse the fix guides

404 when you refresh a page

We request a made-up deep link (/__shipvibed_check/deep/route). If your home page is a single-page app (an empty #root or #app div plus a JavaScript bundle, which is what Lovable, Bolt and Vite produce) and that deep link returns 404, refreshing any page except the home page will break, and so will every link people share. The fix is one rewrite rule. Server-rendered sites are expected to return a real 404 here, so they pass.

Fix the 404 on refresh

Secret keys in your JavaScript

We download the same-origin JavaScript your page loads (up to 10 files and 5 MB) and look for keys that should never reach a browser: Supabase service_role keys, Stripe secret and restricted keys, OpenAI, Anthropic, GitHub, AWS and other provider keys. Supabase keys are decoded, and only a service_role key is flagged: the anon key is meant to be public. Anything in your bundle can be read by anyone, so a found key should be rotated, not just removed. We show only the key type, the file and a masked preview like sk_live_…a1b2.

Move secrets out of browser code

Supabase settings to check by hand

If your bundle talks to a Supabase project, we say so and list the two settings that break most launches: the Auth Site URL (still set to localhost on a new project) and Row Level Security. We can’t see either from outside, and we never query your database. Test RLS with a second account: sign in as someone else and make sure you can’t read or change the first user’s data.

Supabase Row Level Security

Localhost leftovers

We look for addresses like http://localhost:3000 or http://127.0.0.1:54321 in your HTML and JavaScript. They work on your laptop and fail for everyone else, often as a login redirect that lands on localhost. We only flag addresses with a port, because libraries use a bare http://localhost internally as a placeholder.

Fix auth redirects to localhost

Title, description, preview image and crawl files

We check for a <title>, a meta description, an og:image (the picture shown when your link is shared), a favicon, and whether /robots.txt and a sitemap exist. Missing ones never break the app, so they are warnings, but they decide how you look in search results and chat previews. Many single-page apps answer /robots.txt with the app’s HTML page; we count that as missing.

Run the full launch checklist

What it can’t see

Only what a browser can download: your HTML and JavaScript. It can’t see your server code, your environment variables, your database rules or your dashboard settings, so a clean report doesn’t mean your Row Level Security or webhooks are right. For those, use the 22-point launch checklist.

Privacy

We make a few GET requests to the public URL you enter, from our server, with the user agent ShipVibedChecker/1.0. We don’t store the URL, the report or anything we download, and found keys are never sent back in full. Private and internal addresses are refused. You can run 10 checks every 10 minutes.