The 6-point check to run before buying a vibe-coded app

A vibe-coded app can be a genuinely great acquisition: real revenue, a real audience, built in a fraction of the time it used to take. It can also be a folder of code nobody understands, wrapped around an API key that stops working the day after the wire clears.

The difference isn't visible in a screenshot. It's visible in six checks. This is the same rubric our Asset Report runs on every listing — run it yourself before you send a dollar.

1. Revenue — verified, not screenshotted

A Stripe dashboard screenshot proves nothing. It can be edited in the browser inspector in about ten seconds. What you want is a live read of the revenue: active subscriptions, real churn, the trailing months of trend.

Ask: is the MRR connected and verified, or attested? Is it growing, flat, or declining — and over how long? A flat $2k/mo that's actually been declining for five months is a very different asset than the number suggests.

2. Code health — tests, freshness, and secrets in the repo

AI writes a lot of code quickly, and quick code rots quickly. Look for:

• Tests that exist and pass (not "the model said it added tests").
• Dependency freshness — a stack pinned to last year's versions is a maintenance bill you're inheriting.
• Secrets committed to the repo. This is the single most common vibe-coding failure. An API key or database credential in the git history is a live liability, and it's depressingly frequent.

3. License contamination — what the model quietly pulled in

Generated code borrows. Sometimes it borrows a dependency under a copyleft (GPL) or non-commercial license that's incompatible with you selling the product. A clean license scan tells you whether the thing you're buying is actually yours to sell — before a lawyer tells you it isn't.

4. IP provenance — can the rights actually transfer?

Who, or what, generated this code, and are the rights assignable to you? If three different contractors and two AI tools touched the codebase and there's no paper trail, "I'm selling you the IP" is a sentence, not a fact. You want clear, human-held, transferable ownership of the asset.

5. Bus factor — how many single points of failure?

The most fragile micro-SaaS dies on one of three single points:

• One API key the whole product depends on (and one provider who can revoke it).
• One external service with no fallback.
• One founder who is the only person who understands how any of it fits together.

Each of these is survivable if you know about it going in and price it accordingly. The danger is discovering them after the handover.

6. Security posture — the obvious holes

You're not running a penetration test. You're checking for the unlocked-front-door class of problem: exposed admin endpoints, missing auth on routes that move money or data, secrets in client-side code. The goal isn't a perfect security audit — it's making sure you're not buying a breach.

Putting it together

No app passes all six perfectly, and it doesn't need to. A great deal is often a flawed asset at a fair price with the flaws visible. The catastrophe is the flaw you never saw — the GPL dependency, the declining trend dressed up as flat, the one key that wasn't yours to transfer.

Diligence isn't pessimism. It's the thing that lets you move fast on the good ones with actual confidence. Every listing in our marketplace ships with this report already run, the revenue verified live, and the deal held in escrow until handover checks out — so the six-point check is done before you ever open a conversation.