I checked 76 live vibe-coded apps. Only 3 got an A.

Everyone has an opinion about whether vibe-coded apps are "safe" or "ready to launch." We wanted numbers instead.

So in October 2026 we took 76 apps that their makers had already launched and listed publicly (mostly built with Lovable, plus a few other builder tools) and ran each homepage through the same free, rule-based check that anyone can run. One check per app, nothing more.

We're not naming any app, and we never will. Everything below is totals and percentages. If you built one of these apps, nobody can tell from this post, and that's on purpose.

The short version

• Grades: 3 A's, 53 B's, 18 C's, 2 D's, 0 F's. Only about 4% got an A.
• 97% were missing basic browser safety settings (called "security headers").
• 67% had at least one problem that makes it harder for Google to find them.
• 22% had a slow or heavy first load.
• 8% had broken link previews, so a shared link shows up blank or half-finished.
• The scary stuff never showed up: 0 apps with a database that answered a stranger, and 0 with private keys sitting in the page's code.

How the grades landed

Most apps landed in the B range. That's better than the "vibe coding is a security disaster" headlines suggest. It's also not great: a B usually means a few easy fixes are still waiting, and about a quarter of apps (20 of 76) scored a C or lower.

The most common problems

The good news is that the top problems are boring and fixable. Here's what each one means, and exactly what to paste to fix it.

Fix 1: Add security headers (97% of apps were missing them)

Security headers are short instructions your site sends to the browser, like "don't let other sites put my page inside a frame" or "only load scripts from places I trust." Visitors never see them, but they shut the door on whole kinds of attacks. Builder tools almost never add them for you, which is why nearly every app was missing them.

The easiest route is to paste this into your builder tool:

Add standard security headers to every page of my site: Content-Security-Policy
(start with a policy that allows my current scripts, fonts and images),
Strict-Transport-Security, X-Content-Type-Options: nosniff,
Referrer-Policy: strict-origin-when-cross-origin, and a frame-ancestors rule so
other sites can't put my pages in a frame. Use my hosting platform's headers
config. Then tell me in plain English what each one does and check nothing on
the site broke.

If you'd rather add them by hand and your site is on Netlify, a file named _headers in your published folder looks like this:

/*
  Strict-Transport-Security: max-age=31536000; includeSubDomains
  X-Content-Type-Options: nosniff
  Referrer-Policy: strict-origin-when-cross-origin
  X-Frame-Options: DENY
  Permissions-Policy: camera=(), microphone=(), geolocation=()

On Vercel, the same idea goes in vercel.json:

{
  "headers": [
    {
      "source": "/(.*)",
      "headers": [
        { "key": "Strict-Transport-Security", "value": "max-age=31536000; includeSubDomains" },
        { "key": "X-Content-Type-Options", "value": "nosniff" },
        { "key": "Referrer-Policy", "value": "strict-origin-when-cross-origin" },
        { "key": "X-Frame-Options", "value": "DENY" }
      ]
    }
  ]
}

We left Content-Security-Policy out of the hand-written versions on purpose. It's the most powerful header, but a wrong one can blank your site. Let your builder tool write it for your actual scripts, then click through every page afterward.

Fix 2: Tell Google which address is real, and give it a map (67% had a Google issue)

Two problems drove most of this.

No canonical tag (54% of apps). If your app answers at both www. and the plain address, or with and without a trailing slash, Google may treat those as different pages and split your ranking between them. A canonical tag tells Google which address counts. In each page's <head>:

<link rel="canonical" href="https://yourdomain.com/pricing" />

Each page should point to its own address on your real domain. A common mistake is pointing every page at the homepage, or at a preview address like something.lovable.app. The prompt version:

Add a canonical link tag to every page that points to that page's main https
address on my real domain (not a preview or .app address). Make sure each
page's canonical is its own address, not always the homepage.

No sitemap (28% of apps). A sitemap is a list of your pages that Google reads. Without one, Google has to find pages by following links, and new pages can take weeks to show up. A minimal sitemap.xml at the root of your site:

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url><loc>https://yourdomain.com/</loc></url>
  <url><loc>https://yourdomain.com/pricing</loc></url>
</urlset>

And a robots.txt next to it that points Google there:

User-agent: *
Allow: /
Sitemap: https://yourdomain.com/sitemap.xml

Leave login, dashboard and account pages out of the sitemap.

Fix 3: Make your link previews work (8% were broken)

This one is less common, but it hurts exactly when it matters: launch day. When you paste your link into X, Slack, iMessage or a Discord server, the preview card comes from a few tags in your page's <head>. Without them, your link shows up as a bare address with no picture.

<meta property="og:title" content="Your App – what it does in a few words" />
<meta property="og:description" content="One sentence a stranger would care about." />
<meta property="og:image" content="https://yourdomain.com/og-image.png" />
<meta property="og:url" content="https://yourdomain.com/" />
<meta name="twitter:card" content="summary_large_image" />

Use a full https:// address for the image (not /og-image.png), and make the image 1200×630. Then paste your link into a private chat with yourself before you post it anywhere public.

Bonus: the slow first load (22% of apps)

About one in five homepages took noticeably long to arrive or were heavy. On a phone with weak signal, that's when people give up. The usual causes are huge images and big scripts loading before anything shows. Ask your builder tool to find the biggest causes, fix them without removing features, and tell you the before and after sizes.

The good news: the scary stuff was rare

Here's what surprised us. The check also looks at whether your database answers strangers who aren't logged in, and whether private keys are visible in your page's code. In this sample, neither showed up even once. Plenty of these apps talk to Supabase straight from the browser. That's normal and fine when it's locked down, and none of them let a stranger read data on the checks we ran.

A fair warning, though: the check only looks at the homepage and what it loads. It can't log in, so it doesn't see what's behind your sign-in page, and "we didn't find it" isn't the same as "it isn't there." If your app stores anything private, test it like a stranger would: open it in a private window, signed out, and see what loads.

How we did this

• Which apps: 76 apps whose makers had already listed them publicly with a live link, mostly from community showcase pages. We left out a few that were offline or wouldn't load.
• What we ran: one free check per homepage, the same request any visitor can make, at the same speed limit. No logins, no guessing at hidden pages, no extra probing.
• What we kept: only the grade and the type of each problem. No keys, data or other details from the apps.
• Limits: homepage plus the scripts it loads, not every page. It's a snapshot from one day in October 2026, and apps change all the time.

What this means if you're about to launch

The apps in this study weren't broken. Most were one or two prompts away from an A. The problems that showed up most are the invisible ones builder tools skip and nobody notices, until Google ignores your site or your launch link shows up blank.

We built Throttle Bird to run these checks: free scan, with paid reports for deeper fixes. The full original write-up is on our blog.

What's the first thing you check before you ship? I'd love to hear it in the comments.