Vibecode Rescue: Auditing Vibecoded Apps for Common Mistakes and Failures

There's a lot of vibecoded software shipping right now and the quality runs the whole range. Some of it is very good, plenty of it is fine, and some of it should not be accepting a credit card.

You can't tell which is which from the landing page.

Why am I doing this

Because I'm concerned that there is so much vibecoded software out there that looks like a product but isn't. The landing page might be clean, and trick a few people into signing up; and putting their information at risk.

Also I care about the people who are building this stuff. Agentic coding is a new skill, and it's easy to get it wrong. I want to help people ship better products, and I want to help people avoid shipping products that aren't ready or that will never convert.

A perfect example is paylog.space. It tracks your recurring subscriptions and tells you where your money is going. The hero copy is clear — "Track Your Recurring Payments. Stop Wasting Money." — and the pricing table behind it is clean. The privacy policy has a real retention section with specific numbers in it: 30-day deletion, 90-day backup purge, seven-year transaction records. That's more specific than most policies I read.

It looks like a product. It asks you to upload your financial information.

Then you look at it for ten minutes.

feature copy      →  names the product "PayPing"      (a different product entirely)
privacy policy    →  routes all rights requests to @paylog.app
                     (paylog.app resolves to IONOS infrastructure — not theirs)
policy §"where"   →  "Paylog is based in [Your Country/Region]"
meta description  →  "Join 10,000+ users"             (appears nowhere on the page)
dashboard mock    →  header says 5 active subs, summary card says 12  (same screen)
data export       →  gated behind the Pro tier        (GDPR Art. 20 doesn't allow that)

Every one of those is two generated artifacts that were never checked against each other. Each piece is individually plausible. Nothing agrees with anything else.

The contact addresses don't work either, so there's no way to tell them:

$ dig +short paylog.space MX          # (empty) — support@paylog.space bounces
$ dig +short paylog.space TXT | grep spf   # (empty) — domain is spoofable
$ dig +short _dmarc.paylog.space TXT  # (empty)

$ dig +short paylog.app MX            # someone else's mail server
10 mx00.ionos.com.
10 mx01.ionos.com.

The privacy policy sends data-deletion requests, CCPA requests, GDPR requests, and children's-data removal requests to addresses on paylog.app. That domain has live mail on IONOS and has nothing to do with this product. Somebody has been receiving other people's data-protection requests.

One Wayback capture, dated 2026-05-11, against a meta description claiming ten thousand users.

Built, launched, abandoned.

Code got cheap; products didn't

I'm not here to argue that agents write bad code. Mostly it depends on the human that is driving that agent. What changed alongside cheap code is the ability to cheaply generate the surface of a product.

A landing page, a terms page, a privacy policy, a pricing table, feature copy that scans well — all of that used to cost real money or real hours. That cost is precisely why people learned to read it as a signal. Someone who bothered to write terms probably also bothered to configure their mail, make sure the application is reasonably secure, etc.

None of that holds anymore. The surface is free now, and it looks the same whether there's a company behind it or nothing at all.

So the things an agent still won't do for you are the things that decide whether you have a product. Getting data into the app — imports, connectors, parsers, OAuth flows — is unglamorous and doesn't emerge from a prompt. Neither does checking your own output. Neither does taste. A lot of people building this way have never shipped a product before, so they don't know those parts exist, and the generated app looks finished enough that nothing tells them.

Protecting Users, Helping Founders

The user is the one I care about first. Vibecode products exist in every cohort and vertical, including ones that ask for sensitive information like bank details, private repositories, email contents, and filesystem access, and a normal person evaluating one has no way to check any of it. They read the landing page, get a false sense of security, and hand over their data.

I also want to help the founders. The things that I find are often things that a founder could have found themselves if they had taken the time to look. And this category of issues will more than likely cost them conversions.

What this series is

I'm going to review SaaS apps of all types, and sizes but will primarily focus on those that are recently launched, and haven't really converted. There are plenty of public directories listing apps and self reporting revenue.

I'll look at them from a product perspective, and score them on the fundamentals of what makes a product a product. The goal is to help founders understand what they are missing, and to help users understand what they are getting into.

This is not a leaderboard and it's not a shaming exercise. The goal was never for anyone to score a hundred; it's whether the fundamentals are there. Whether the founders and operators care to take the feedback is up to them, and the reader learns from it either way — which is the point of writing any of this down.

How I'll look, and what counts as a finding

Everything I score comes off the shipped bundle, the app's own network calls, response headers, public pages, public DNS, and whatever I see after signing up like a normal user. Probing, fuzzing, enumeration and auth bypass are out of bounds, and nothing goes near another user's data. Anyone can re-run the same fetch and get the same file.

If I find a real vulnerability it goes to the operator privately, and gets published once it's fixed or after a stated window.

Every finding carries a marker:

Confirmed   directly observed — bundle line, request, response, metric
Inferred    strongly implied by observable shape; never written as fact
Unknown     opaque from outside to anyone, including your own users

Unknown is the one that matters. I can't tell from outside whether your authorization is enforced server-side, and neither can your users, their security reviewer, or an acquirer doing diligence.

Every number points at a file — a saved run, with a UTC timestamp, because sites change while you're writing about them.

Dogfooding the audit

Before any of this points at somebody else's work, it pointed at mine. I ran the same process against ShipLog, black-box, with the repository access I obviously have deliberately unused.

It came back 77. Fragile, not Solid, and it lost most of its points on fundamentals rather than on engineering.

I lost quite a few points on something that I did deliberately but would still be perceived as a miss. shiplog.ca had no MX record, so the hello@shiplog.ca address published nine times across the site couldn't receive mail. My rationale at the time was ShipLog should collect feedback through its own widget, and I didn't want support arriving by email.

The reasoning was okay, but the outcome was wrong. From outside, a rights-request address in a privacy policy that silently bounces looks identical whether you meant it or not; users are not mind readers. I fixed it; the score went up.

Disclaimer

This series is free and in public, but I also sell fixing this exact kind of problems as a service. The paid version is a Code Health Check, and the rescue work that tends to follow one is a service I offer, you can find it as Track 03 on my services page, and the package is called Vibecode Rescue, same as this series.

That said, I'm not writing this series to sell you or the sites under audit anything. I want to help people ship better products, and avoid painful lessons that will kill their attempts and potentially damage their users if things go really sideways.

First article in the series is paylog.space, in full, with the evidence. After that I'd like to do products that are still alive and still trying, because a post-mortem on an abandoned app is the easy version. If you've built something and you want it looked at properly, see the email below.