DEV Community: Throttle Bird

I ran a free launch check on 34 vibe-coded apps shared this week. Here's what I found.

Throttle Bird — Sat, 24 Oct 2026 22:54:53 +0000

Every day on X, people share apps they just built with Lovable, Base44, Bolt or Cursor. I wanted to know what those apps look like from the outside on the day they're shared, so this week I ran our free Throttle Bird check on 34 of them.

I'm not naming any app, and I never will. Everything below is totals. If you built one of these apps, nobody can tell from this post.

The short version

I checked 34 live apps that their makers shared publicly on X between Oct 20 and Oct 24, 2026. Most were built with Lovable or Base44. 15 were on a lovable.app address, 11 on a base44.app address, and 8 on their own domain.
The good news first: none had a secret key sitting in the page, and none had a database that answered a stranger.
100% were missing basic browser safety settings (called "security headers").
85% had no sitemap and 79% didn't tell Google which address is the real one, so new visitors from search will have a hard time finding them.
47% had a first load that was slower than it should be.
29% had missing or incomplete social preview tags, so a shared link can show up blank.
Grades: 8 B's, 23 C's, 3 D's, no A's. The typical app had 4 things to fix, and most of them take one prompt to your builder.

Two more apps I picked were already offline when I checked, so I left them out.

Why this matters on launch day

None of this means these apps are bad. Most of them are genuinely cool, and a C here usually means a handful of boring settings nobody told the maker about. But launch day is when strangers show up for the first time, and it's also when a missing setting is most likely to cost you a visitor, a signup, or a bad first impression.

Here's what each one means and what to paste into your builder to fix it.

1. Security headers (every app was 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 close the door on whole kinds of attacks. Builder tools almost never add them for you.

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.

Some builder hosting doesn't let you set these yourself yet. If yours doesn't, it's worth asking their support, or connecting your own domain through a host that lets you add headers. We have a longer guide here: how to add security headers to your vibe-coded app.

2. Google can't find you easily (85% had no sitemap)

A sitemap is a list of your public pages that Google reads. A canonical tag is a hidden line on each page that says "this is the real address." Without them, a brand-new app with few links can take weeks to show up in search, or show up under the wrong address.

Create a sitemap.xml at the root of my site that lists every public page with
its full https address on my real domain, and a robots.txt that allows search
engines and points to the sitemap. Add a canonical link tag to every page that
points to that page's own main https address. Leave out login, dashboard and
account pages.

If you want the full walkthrough, read why your vibe-coded app isn't on Google.

3. A slow first load (47%)

About half the apps took longer than they should to send the first page. On a phone with a weak connection, that's the moment people give up.

Make my homepage load faster for first-time visitors: compress and resize
images, lazy-load anything below the fold, remove unused libraries, and set
sensible cache headers for static files. Tell me what you changed and how much
smaller the page got.

4. Blank link previews (29%)

When someone shares your link on X, iMessage or Slack, the preview card comes from a few hidden tags. If they're missing, your launch post shows a bare link.

Add Open Graph and Twitter card tags to my homepage: og:title, og:description,
og:image (a 1200x630 image of my app), og:url with my real address, and
twitter:card set to summary_large_image.

The good news, again

I want to say this clearly because the "vibe-coded apps are a security disaster" take is everywhere: in this sample, no app leaked a secret key in the page and no database answered a stranger. That's better than I expected. What's left is mostly settings that take a few minutes each.

That matches what we saw earlier this month when we checked 76 apps from public directories. Almost every app was missing security headers, and the dangerous problems were rare.

How I did this

I picked apps their makers had shared publicly on X this week, mostly from "built with Lovable" posts and the Base44 challenge. I didn't choose apps based on how they looked.
Each homepage got exactly one run of the same free check anyone can run on throttlebird.com. No logins, no extra probing, homepage only.
I only kept totals. I didn't store any key, table name, or detail that could help someone target a specific app.
34 apps is a small sample, so treat the percentages as a rough picture, not a census. I'm going to run this again next week and compare.

If you're about to launch, you can run the same free check on your own app. It takes under a minute and you don't need to sign up. If you shared your app on X this week and want the full report, reply to me @ThrottleBirdhq and I'll send it over free.

Jordan

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

Throttle Bird — Sun, 18 Oct 2026 16:13:42 +0000

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.