You Vibe-Coded an App. Now What? The Post-Ship Playbook

You pasted the URL into a group chat. Someone said "nice." The deploy went green, the signup form works, the dashboard renders, and — after a day or two — nothing else happens. The app is live. It is also, in every way that matters, still a private object: one account, your data, your browser, your idea of what it does.

Lovable says a million new projects are started on it every week and more than 50 million have been built in total. It also says the apps built on it draw about 720 million visits a month, combined. Divide one by the other and you get roughly fourteen visits per project per month — our arithmetic, not theirs, and averages lie upward: a handful of hits drag the mean far above whatever the typical project actually sees. How we got here is its own story. This post is about what happens next.

Here is the uncomfortable version. Almost everything wrong with a freshly vibe-coded app is invisible from the chair you built it in. It works because you are its only user. It stays "fine" until one of four visitors shows up: a second account, a stranger, a crawler, and someone willing to pay. Each of them finds a different product than the one you tested, and the order they arrive in is the order they cost you.

So this is a map, not a list of tips. Each visitor gets a section, a diagnosis, and — because the details run long — a hand-off to the post that owns them.

You Are Not Early. You Are in a Stampede

Two numbers to hold in your head, from opposite ends of the pipe.

Supply. Apple's App Store took on 557,000 new apps in 2025, up 24% on 2024 and the first real rise since 2016, according to Appfigures — which names vibe coding as the cause. Appfigures data reported by TechCrunch puts releases up 60% year over year in the first quarter of 2026, and 80% on iOS alone. Apple itself says AI tools are driving "a surge in app submissions": its review team evaluated 9.1 million of them in 2025 and rejected more than 2 million, including 371,000 as copycats, spam, or misleading. Submissions count updates and resubmissions, so 9.1 million is not 9.1 million products — but the queue is real. On the subscription side, RevenueCat's 2026 report, using Appfigures data, counts new subscription apps launching at about 2,000 a month in January 2022 and more than 14,700 a month by January 2026.

Demand. Sensor Tower counts 149 billion app downloads in 2025, one per account — growth of 0.8%. Appfigures, counting differently, has the year slightly down. Pick either vendor and the shape is the same: flat. The top 1% of publishers took 92% of in-app purchase revenue, $154 billion against $13.1 billion for the other 99% that earned anything at all. Sensor Tower frames that as mildly good news, and fairly: the bottom 99%'s slice has grown from 5% in 2019 to 8% now. But a slice of a pie that isn't growing, split among seven times as many launches, is a thinner slice. RevenueCat's cohort chart makes it concrete: apps launched in 2025 or later — "the vibe coding era," in their words — earn 3% of all subscription revenue. Some of that is just age. Not all of it.

These are app-store numbers, and iOS numbers at that — Google Play spent the same period deleting its long tail, and now makes a new personal developer account run a closed test with at least twelve testers for fourteen days before it can even apply to publish. Nobody publishes an equivalent for web products. But the shape is the same one we see in the SaaS Cubes review queue: a lot more things being made, and a flat number of people to make them for.

The Four Visitors Your App Has Never Had

The four are not a metaphor. They are literally the four things a solo builder never does to their own product: log in as someone else, hand it to a person who doesn't care, look at it the way a machine does, and ask it for money.

Order matters more than any single row. Send strangers to an app the second account would have broken, and you burn the strangers. Get recommended by an assistant before your pages exist in HTML, and there is nothing to recommend. The rest of this post takes the visitors in sequence.

Visitor One: A Second Account

Start with the finding that organizes everything else. Bilal Shahid at AxonBuild reviewed 26 AI-built apps at the code level over June and July 2026 and sorted what broke into fourteen recurring problems. Then he made the observation this whole post hangs on:

Thirteen of the fourteen recurring problems need something the owner never does: a second account, a stranger, real traffic, or a customer who finally says something.

The one problem an owner can see alone is fabricated demo data presented as real output. Everything else on the list — cross-customer data access by a logged-in user, unauthenticated endpoints doing privileged work, a server trusting whatever the browser sent — only shows up when someone who isn't you touches the product. AxonBuild is upfront that the thirteen-of-fourteen split is a judgment about each problem's mechanism, not a measurement, and twenty-six apps — eleven used to build the pattern list, ten unseen, five of the author's own — is a small sample from a company that sells audits. It still maps exactly onto what the larger scans find, so treat it as the lens, not the statistic.

The statistics come from Reeve, which passively scanned 30,998 live vibe-coded apps over three days in August 2026 — no logins, no exploitation, just what any anonymous visitor could observe. Read Reeve's own caveat before its numbers: "99% of the 30,998 apps we scanned had at least one finding. Most of those were moderate, and nearly all of them are missing browser security headers." Reeve splits its findings into what the hosting platform controls — headers, source maps, certificates — and what only the builder controls, and then makes the point this section rests on: every critical finding in the report sits on the builder's side. Most apps pass most checks; 96% shipped no secret of any kind. 452 apps — about one in 69 — sat at D or F, and because Reeve caps any app with a single critical finding at D, that is roughly the count of apps with, in Reeve's words, "a hole a stranger could walk through today."

The hole is usually the database. Of the 3,680 Supabase-backed apps whose database could be checked from outside, 2,096 — 57% — had at least one table a stranger could read with a single request and no password; 394 of those tables were named things like users, profiles, orders, or messages. (Reeve's summary table restates the same 2,096 as 8% of a larger base, so name your denominator if you quote it.) One in 23 apps shipped a secret key in public code, 1,332 in total — and Reeve immediately does the honest arithmetic: 1,142 were Google browser keys, which are meant to be public, and 52 were keys that "can spend money or read the whole database." Fifty-two out of 30,998 is about one in six hundred. Thirteen percent published source maps, which in Reeve's own grading "shows an attacker where to look, and hands over nothing on its own."

Two other studies point the same direction. A June 2026 arXiv preprint audited 200 publicly deployed vibe-coded apps and found 91% contained at least one vulnerability, concentrated in broken access control and authentication failures — precisely the class a second account surfaces — and traced them to three systematic limitations of the coding agents themselves, which better prompting reduces but does not remove. Symbiotic Security's scan of 1,072 live Supabase-backed apps found 39 with tables fully readable to anyone and 172 that let anyone delete records with no authentication at all; write access was four times as common as full read access. AxonBuild's own ledger across its 21 third-party apps: 7 with confirmed cross-user authorization failures, 9 with row-level-security gaps, 11 with an unauthenticated endpoint doing privileged work, and 12 of the 14 apps with an AI feature carrying a path for a stranger to run up the owner's model bill.

If you want the canonical example, it has a name: CVE-2025-48757, a critical-rated flaw from 2025 in which insufficient row-level security in Lovable-generated sites let unauthenticated visitors read or write arbitrary database tables. The researcher's scan of 1,645 sites on Lovable's own showcase — homepages only, no logged-in areas — found 303 exposed endpoints across 170 projects, about one in ten. The record is formally disputed: the vendor's position is that each customer "accepts a responsibility over protecting the data of their application." That dispute is the most useful thing about the CVE. It is the exact boundary between "the platform shipped it" and "you shipped it," and the second one is where you live now. A month after the platform added a security scanner, the same researcher retested a paid site maintained by a Lovable employee, removed the authorization header, and inserted a record with payment_status set to paid — bypassing Stripe. His verdict on the scanner: it "merely checks for the existence of any RLS policy, not its correctness." A green check from the platform is not one of the four visitors.

Here is the second-account visit, condensed from AxonBuild's follow-up on checks you can run without reading code, plus Reeve's categories. AxonBuild is specific that its ten checks take twenty-two minutes, not twenty; this shorter list needs a second email address and most of that.

• Open a private window and paste your dashboard or admin URL straight in. A redirect to sign-in is the pass; a rendered page is the fail.
• Signed in as account A, create one record you will recognize. Sign up as account B from the private window and request account A's record through the same path — read, edit, and delete.
• In your database console, confirm row-level security is enabled on every table that holds user data, and that each policy names the owner column.
• Search your shipped JavaScript bundle for sk_, sk-ant, AKIA, and service_role. Anything found is a rotate-now, not a fix-later.
• Load a page with the browser's developer tools open and check the Sources panel for .map files. If your original source is readable, turn source maps off for production.
• Delete the demo data. If your dashboard shows numbers you never entered, a stranger will assume everything else is fake too.
• Find the endpoint that costs you the most per call — usually the one that talks to an AI model — and confirm it requires a session and has a rate limit.
• If any user input is sent to a third-party AI, say so before the user types. Apple's guidelines have required disclosure and explicit permission since November 2025, and most vibe-coded apps do neither.

The click path for each of these differs enough between Lovable, Bolt, v0, and Replit to deserve its own write-up, and the launch playbook's pre-launch checklist covers the non-security half of the list. Do this half first. Everything after it assumes the product holds.

Visitor Two: A Stranger Who Owes You Nothing

This section is short on purpose, and it is not about where strangers come from — that post exists and is the one to read next. This is about what a stranger is for, which is different: a stranger is a measuring instrument.

The research on first impressions is older and more careful than the folk version. Microsoft Research's dwell-time study of 205,873 web pages found that the risk of abandoning a page is highest in the first moments of a visit and falls the longer someone stays — "negative aging," in the paper's language, on 98.5% of pages. Jakob Nielsen read the same curves as a ten-second screening window that flattens after about thirty seconds. That is his interpretation, not the paper's, and it is about web pages, not products. It is still the correct posture: a stranger decides whether to keep going before they have found the feature you're proudest of.

How many strangers do you need? Nielsen's famous answer is five, which finds "about 85%" of usability problems — if the average problem is found by about a third of users, which is the assumption the whole rule rests on. When Laura Faulkner actually tested sixty people on one task in one application and drew random groups of five, some groups found 99% of the problems and others found 55%. Spool and Schroeder, on four production websites, found five users nowhere near enough. Their recommendation is the practical one for a solo builder: a user or two every week, not a study of eight every six months.

And the benchmarks for what a stranger does inside a funded, staffed SaaS product are humbling. Userpilot's benchmark, from 62 companies on its own platform, puts average activation — the share of signups who reach the product's defined value moment — at 37.5%. Across 188 companies, onboarding checklist completion averages 19.2% — and the median is 10.1%, so the typical product's checklist is finished by one user in ten. Average time to value is about a day and a half. Those companies have onboarding teams. Your app has never met a stranger.

If the stranger doesn't understand what the product is, that is not an onboarding problem. It is a positioning problem, and validation is where it gets fixed.

Visitor Three: A Crawler That Never Runs Your JavaScript

There is a genre of article aimed at exactly you, with titles like "Why Your Lovable Site Is Invisible to Google." Most of it sells prerendering services, and most of it is wrong about Google. Here is what is actually true, in both directions.

Google renders JavaScript, and says so. Google's own documentation, updated March 2026: every page returning a 200 status is queued for rendering, and "once Google's resources allow, a headless Chromium renders the page and executes the JavaScript." Vercel and MERJ measured the wait in 2024 across 37,000 matched crawl-and-render pairs: a median of ten seconds, with a long tail — about three hours at the 90th percentile — on fast, professionally built sites. Lovable's own docs go further: apps created from May 13, 2026 ship with server-side rendering, and older apps get on-request prerendering. If your site is not in Google, a client-rendered shell is rarely the reason. Having no domain, no content, and no links is the reason.

Now the part the vendors don't sell, because it isn't fixable with their product. In December 2024, Vercel and MERJ analyzed crawler behavior across their network and found that seven named AI crawlers — OpenAI's GPTBot, ChatGPT-User and OAI-SearchBot, Anthropic's ClaudeBot, PerplexityBot, Meta's and ByteDance's — did not render JavaScript. ChatGPT's crawlers downloaded JavaScript files in 11.5% of requests and Claude's in 23.84%; they simply never executed them. (The same study found that Gemini's crawler, riding on Googlebot's infrastructure, and AppleBot do render — and it left Microsoft Copilot out entirely for lacking a unique user agent, which is part of how "no AI reads JavaScript" hardened into folklore.) That finding is nearly two years old, so it needs a 2026 check, and there is one: in January 2026 the agency Résonéo planted sentinel strings in fifteen kinds of page content and asked eight assistants to report what they saw when handed the URL. ChatGPT, Claude, and Gemini read HTML only. Grok and DeepSeek ran JavaScript fully; Bing Copilot ran inline script but gave up after about fifty milliseconds, missing anything that arrived late — which is most of what a client-rendered app is. And Google's AI Mode and AI Overviews cannot fetch a URL at all; they answer only from Google's index. So the blanket claim "no AI reads JavaScript" is now false — and the three assistants most of your buyers actually use still don't. Google's own JavaScript guide says it in one line: server-render, because "not all bots can run JavaScript."

That last row is the quiet trap. Lovable serves prerendered HTML "when a verified crawler arrives"; unverified agents, including the SEO scanner you paid for, see the single-page app. So the scanner tells you Google can't see you (false), while an AI crawler Lovable doesn't recognize really can't (true), and both problems go away the same way: put the pages that matter in the first HTML response, on a domain you own.

On the domain: lovable.app, vercel.app, replit.app, bolt.host, and their siblings are all on the Public Suffix List, submitted by the vendors themselves. That is a cookie and origin boundary, not a Google penalty — Google has published nothing saying a subdomain ranks worse, and Lovable's own docs recommend a custom domain to "consolidate your brand and search presence," not because the subdomain is punished. What the shared domain does cost you is documented and boring. Lovable states that unpublished projects and branded workspace URLs "are never indexable." Search Console won't give you a domain property, because that needs a DNS record on a domain you control — a URL-prefix property still works. Vercel serves noindex on every preview deployment and on the previous production deployment the moment you promote a new one, and serving the same site at both your-app.vercel.app and yourdomain.com creates a duplicate that needs a canonical tag and a redirect. None of this is search magic. All of it is the difference between owning an address and borrowing one.

Why does the crawler visitor matter so much for a brand-new product? Because of what the assistants do when they don't know you. An early-2026 preprint sampled 112 startups from Product Hunt's 2025 top 500 and ran 2,240 queries: a small ChatGPT model recognized the products by name 99.4% of the time and surfaced them unprompted in 3.32% of discovery-style answers. A thirty-to-one gap between "knows you exist" and "recommends you." For Perplexity, the signals that correlated with being surfaced were the old ones — referring domains and, more strongly, community presence — and the "GEO score" of a product's own site correlated with nothing on either model. Which is the whole thesis of our AI search post: assistants repeat the web's consensus about you, and you cannot write that consensus on your own domain. The backlink and domain authority games didn't end. They got a second customer that reads only HTML. Whether an llms.txt file helps at all is a separate, contested question; the uncontested part is that the machine has to be able to read the page first — something we learned building for machines ourselves.

Visitor Four: Someone Willing to Pay

You will see a statistic about this visitor everywhere. It is almost always wrong in the same way.

The better data is mobile, and it is brutal. RevenueCat's 2026 report draws on 115,000-plus subscription apps that had already integrated its tooling and cleared a minimum-traction bar. One year after launch, the median app makes about $72 a month. Among apps old enough to have two years of history, 17.3% ever clear $1,000 a month and 4.6% ever clear $10,000 — and in the Business category, the nearest thing to a solo SaaS, 1.6%. Adapty's panel of 16,000 subscription apps says 57.7% of new ones never cross $1,000 in lifetime revenue, and the top 10% of apps in that panel take 94.5% of its subscription revenue. Both are vendor panels of apps that were already trying to charge — the median across everything anyone ever shipped is lower. RevenueCat's own summary is the line to keep: "No-code tools, game engines like Unity, and now vibe coding have all promised to democratize app building. None eliminated the real barriers: distribution, product intuition, and the compounding advantage of iterating on user feedback." And no dataset anywhere records how an app was built, so there is no honest figure for "how many vibe-coded apps make money." Anyone who gives you one made it up.

What you can control is whether the fourth visitor can find a price. That is the one move in this post that serves all four visitors at once: a public price tells the stranger who this is for, gives the crawler a fact to quote, and forces you to name the thing you're selling. The evidence is directional but consistent. HockeyStack's analysis of 31 million visitors across 80 B2B SaaS companies found that hiding the price produced more form fills — 4.6% versus 2.8% — and worse ones: leads from transparent pricing pages turned into pipeline 1.7x more often. On mobile, RevenueCat finds apps that ask for money upfront convert five times better than freemium, 10.7% to 2.1%, with nearly identical retention a year later. ChartMogul's survey of 200 software products, mostly B2B, run in January 2026, puts the median free-to-paid rate at 8% — with a tenfold gap between the top and bottom fifth — and trials that require a card at about 30% — a selection effect as much as a funnel effect, which is the point: the number you get to brag about depends entirely on who you let in the door. Which model fits your product is its own decision. Making one and publishing it is not.

Most of the apps in the stampede will quietly stop being maintained within the year; why they die deserves its own post. The ones that don't are, overwhelmingly, the ones whose builders charged somebody early and learned something from the no.

What Not to Do in Week One

The anti-playbook. Every entry is a mistake of order, not of channel — the channels themselves are covered elsewhere.

• Rewriting it "properly" before anyone has used it. The second account finds the bugs in twenty minutes. A rewrite finds them in six weeks, in a different codebase, with the same blind spots, because you are still the only user.
• Launching on Product Hunt as step one. Product Hunt features roughly eighteen products a day — we counted, across seventeen days this August and September, and the number has been flat since 2024 — and its own team decides which, against published criteria that explicitly exclude directories and, as its newsletter put it back in 2024, "everyone's AI wrapper." Its CEO, Rajiv Ayyangar, retired the annual awards in late 2025 for quarterly ones based on traction, writing that "a flashy launch is great, but it tells only a tiny part of the story." And the ceiling is the sobering part: when Dub finished #1 for the day, the week, and the month at once, launch day brought 2,000 visitors and 663 signups. That is the best day the platform offers. Launch as amplification, after the second account and the stranger have been through.
• Submitting to twenty directories in one afternoon and waiting. Listings compound; they don't spike. Pick the curated ones, do them once, and don't mistake the afternoon for distribution.
• Adding features to fix the silence. Silence is the stranger not arriving, not the stranger leaving. No feature fixes a visitor who never came.
• Buying links or "AI SEO" before your pages exist in HTML. The 2026 preprint found GEO scores correlated with nothing. A crawler that receives an empty shell has nothing to work with. Fix the page, then the domain, then worry about the rest.

The First Two Weeks, In Order

Most of the million projects started this week will make nothing, and that is fine; most of them were never meant to. The ones that become businesses are not the ones with the best code. They are the ones whose builders let a stranger in before the stranger let themselves in.