He is right about liability.
He's right about accountability. He's right that regulation is coming — the EU's Product Liability Directive already includes software and AI systems, and the FTC is taking action against deceptive AI product claims.
The short version
I had a beautiful app. Gorgeous UI, working dashboard, 234 visitors, and one PayPal approval away from taking real money. Then I actually audited it.
Three paywall bypasses. A dead admin panel. Silent payment failures. A webhook that double-counted sales and blocked real buyers. My app was not ninety percent done. It was about half done, and everything looked finished.
This is what 827 credits and $248 bought me, what a senior developer told me I still got wrong, and the audit rubric I built so it never happens again.
A vibe coding post-mortem
I Burned 827 Credits and $248 Learning That "90% Done" Is a Lie
I had everything.
This is my personal nightmare. If you're vibe-coding an app right now, you might be living it too. I'm documenting the crash so you can avoid it.
The Hook: The PayPal Trap
The UI was gorgeous. The dashboard flowed. The checkout page looked like something you'd actually pay on. I had user roles, admin panels, course lessons, ticket systems, founder tools, template libraries — the whole stack. Lovable said "deploy successful." My project had 234 visitors. I was this close.
The only thing missing? PayPal auto-payment integration. My business account was pending approval. So I waited. And waited. Two weeks of staring at a "pretty much done" app, unable to flip the switch because PayPal hadn't emailed me back yet.
Then I ran the QA audit.
I hired four parallel research agents to sweep the entire repo. Schema. RLS policies. Every supabase.from() call. Every webhook. Every admin function. I thought they'd find a few rough edges — maybe a missing index, a sloppy loading state.
They found three critical paywall bypasses, a dead admin page, silent payment failures, and a webhook that double-counts sales.
My app wasn't 90% done. It was maybe 50% done. And the scariest part? I had no idea. Everything looked finished. The demo worked perfectly — because I was the only user. The moment a real customer hit "pay," the whole thing would have unraveled.
I spent 827 credits on this project. At $30 per 100 credits, that's roughly $248 — not counting the hours. And I was one PayPal approval away from launching a broken product to real people.
The Vibe Coding Fantasy
Here's how AI app builders sell you a dream: "Describe your app. We'll build it."
You prompt. It generates. You tweak. It deploys. The UI is stunning. The animations are smooth. The database is wired. You show it to a friend and they say "wow, you built this?"
You feel like a founder. But you're not. You're a vibe coder. And there's a difference.
A founder ships something that works — payments process, data stays private, users get what they paid for, the admin panel actually saves settings. A vibe coder ships something that looks like it works — until the first real user breaks it.
The problem isn't the tools. The tools are incredible. The problem is that AI app builders are painters, not architects.
They'll give you a beautiful facade. They won't tell you the foundation is cracked. And they definitely won't tell you that your "90% done" app is actually a house of cards.
What I Found When I Actually Looked
Here are the real issues my audit uncovered — translated from developer-speak to plain English, because that's what you need to hear.
Nightmare 1 — The Invisible Paywall.
I had a "Founder" plan. $67/month. Exclusive tools, blueprint builders, retainer workflows — the premium stuff. The problem? Any logged-in user could access it. Not just paying customers. Anyone with a free account. The app checked "are you logged in?" but never checked "did you actually pay for the founder plan?" The UI hid the buttons for non-paying users, sure. But if you knew how to call the API directly — which any developer, or any curious user with browser devtools, could figure out — you got the full founder experience for free. What this means in real life: you think you're running a subscription business. You're actually running a free service with extra steps.
Nightmare 2 — The Dead Admin Panel.
My admin settings page looked professional. Product name field. Price toggle. Signup switch. "Save" button. "Invite Admin" button. None of it worked. The Save button was wired to nothing. The Invite Admin button was wired to nothing. You could type in the product name, click Save, see a nice animation, and nothing happened. No error. No confirmation. The changes evaporated into the void. What this means in real life: you think you're managing your business. You're clicking buttons in a museum exhibit.
Nightmare 3 — The Phantom Booking.
I had a founder booking system. User clicks "Book a Call," picks a time, sees "Booked for Tuesday at 3 PM." Beautiful. The problem? If the database write failed — network hiccup, validation error, RLS rejection — the app still showed "Booked." The error was swallowed silently. The user believed their call was scheduled. I believed I had a lead. The database had nothing. What this means in real life: you show up to a sales call that was never recorded, you both look unprofessional, and trust evaporates.
Nightmare 4 — The Double Sale.
I had Lemon Squeezy webhooks handling payments. When someone bought a plan, the webhook incremented "slots sold" so I could enforce purchase limits. The problem? No idempotency. If Lemon Squeezy retried the webhook — which they do on timeouts, 5xx errors, or network blips — the slot counter incremented again. One purchase became two. Two became three. Eventually the app thought it was "sold out" and blocked real buyers from purchasing. What this means in real life: you think you made a sale. You actually created a phantom sale that eats a real slot, and a genuine customer walks away.
Nightmare 5 — The Self-Publishing User.
I had a ticket system where users submitted support requests. Admins were supposed to review and publish them. The problem? The database let users update any column on their own ticket — including the "is_published" flag. A user could mark their own rant as "published" and it would show up on the public site without admin approval. What this means in real life: you think you're curating quality content. Your users are publishing whatever they want, unfiltered, to your public-facing site.
The Conversation That Changed How I Think
I posted a meme about vibe coders a few days ago. The responses were intense. A senior fullstack developer named Jon Ny dropped a comment that stopped me cold. He wasn't trolling. He was genuinely concerned. And he said something that every vibe coder needs to hear.
Doing an AI-based QA sweep does not transfer responsibility from you to the AI. If you sell the application, make claims about what it does and put customer data through it, you are still the person or company standing behind those claims.
He compared it to saying "I'm basically a certified surgeon because I have ChatGPT next to me telling me what to do." The tool is capable. That doesn't make the operator qualified. Then he hit me with the real kicker: "The much more dangerous question for a customer is what the AI did not find."
He's right about accountability. He's right that regulation is coming — the EU's Product Liability Directive already includes software and AI systems, and the FTC is taking action against deceptive AI product claims.
And he's more right that the dangerous question is what the AI didn't find. That's why the QA rubric is designed to flag probable privilege-escalation paths as "Critical with verification" — never "probably fine." The human still has to confirm the hole is real before fixing it.
When I ran my QA audit, I wasn't outsourcing responsibility to AI. I was using AI as a systematic audit instrument — the same way a senior developer uses static analysis, linting, or test suites. The difference is scale and pattern recognition.
I ran four parallel research agents across my entire repo. One mapped the full Supabase schema and RLS policies. One audited every supabase.from() call against that schema. One checked admin workflows and payment handlers. One traced the dashboard, founder, and launchpad flows.
Then I cross-referenced them. The schema agent found that course_lessons had SELECT USING (true) — wide open. The code agent found that the founder functions never checked plan tier. The webhook agent found that Lemon Squeezy retries would double-count sales. The workflow agent found that the admin settings page was wired to literally nothing. None of these were AI hallucinations. They were verifiable, reproducible findings backed by code and schema evidence.
What AI Can See That Human Eyes Cannot
This is the part that flipped my perspective.
— even a senior one — reads code linearly. They trace one function at a time. They hold the schema in their head. They get tired. They miss the gap between what the React component promises and what the server function actually enforces.
reads the entire codebase simultaneously. It cross-references the schema against every query. It checks whether the RLS policy that looks secure actually matches the column the code writes to. It finds the catch that swallows errors three files deep. It notices the one field on the page with no null guard.
It's not magic, it's pattern matching at scale — exactly where AI excels and human eyes fatigue. But the security framework, the severity rules, the "what matters versus what's noise" judgment, that's all human architecture. The AI executes the sweep. The human interprets the verdict and owns the fix.
The Real Divide
The vibe coders who survive won't be the ones who say "AI built it, AI checked it, I'm good."
They'll be the ones who say: AI helped me see what I couldn't, and I still own every line that ships.
That's the standard I'm holding myself to. And honestly? It's why I think the next few years need more voices like Jon's in this space — not to gatekeep, but to set the floor. The builders who learn to combine AI's pattern recognition with human accountability will be the ones who actually last. The rest will be the cautionary tales he warned about.
The Math That Broke My Heart
Let's talk about what this actually cost me.
| Item | Cost |
|---|---|
| Credits burned on "Dream App Hub" | 827 |
| Dollar value (at $30/100 credits) | ~$248 |
| Hours spent prompting, debugging, re-prompting | ~40+ |
| Critical bugs found | 5+ |
| Paywall bypasses | 3 |
| Features that looked done but weren't | ~50% of the app |
| Confidence that I could launch tomorrow | 0% |
I spent $248 and 40+ hours building something that would have embarrassed me on launch day. Not because I'm bad at this — I'm a developer who knows code. But because vibe coding tools don't audit themselves. They build. They don't verify.
The "90% done" feeling? That was the UI. The paint. The demo. The actual business logic — payments, permissions, data integrity, error handling — was a minefield I couldn't see until I looked.
Why This Happens to Everyone
If you're vibe-coding right now, you're probably in one of three stages.
You're where I was. The UI looks great. You can't wait to launch. You have no idea what's broken.
You're starting to notice glitches. A button that sometimes works. A page that shows old data. You're debugging with prompts, burning credits, hoping the next fix sticks.
The worst stage. Real users found the holes. Refunds. Angry emails. "Why can I access premium for free?" "Why did my payment go through but I got nothing?"
The common thread? No one taught us how to audit a vibe-coded app. We learn to prompt. We learn to deploy. We never learn to verify that the thing we built is actually safe, secure, and functional under real-world conditions.
That's the gap. And that's what I built to fix it.
A QA Skill That Thinks Like an Architect
After the audit, I didn't just fix the bugs. I built a system to prevent them. It's called the Vibe Coder QA Skill — a rubrics-based audit method that works on any AI app builder. Not just Lovable. Not just Supabase. Any vibe-coded project.
| Pillar | What It Checks | Why It Matters |
|---|---|---|
| Access Control | RLS policies, role checks, paywall enforcement | Prevents free users from accessing premium features |
| Secrets & Exposure | API keys, service roles, data leaks | Prevents your database from being an open book |
| Input & Abuse | Validation, idempotency, atomic operations | Prevents double-charges, overselling, and corrupted data |
| Auth Strength | Session handling, MFA, password policies | Prevents account takeovers and unauthorized admin access |
| Dependencies & Repo | Migrations, lockfiles, schema drift | Prevents "it works on my machine" disasters |
Each pillar is scored 1–4. You know exactly where you stand and what to fix first.
What the sweep reports back
You call the skill inside your AI assistant — Claude Code, Lovable's Copilot, wherever you work. It runs a systematic sweep of your codebase, schema, and policies.
Features broken or data exposed. Fix before launch.
Works, but hurts UX. Fix after launch.
Cheap fixes now that prevent expensive disasters later.
No guesswork. No "I think it's fine." Just a clear report with a batched fix list you can apply in one pass.
The Bigger Picture: App Builder Hub
The QA skill isn't just a checklist. It's the foundation of something bigger I built: App Builder Hub. Here's the philosophy: most vibe coders build backwards. They start with the UI, add features, wire the database, and hope it all works. Then they debug for weeks, burning credits, chasing bugs that should never have existed.
App Builder Hub flips the script. You start with a Copilot Architect that has the QA skill built in from day one. Before a single component is generated, the architect:
With RLS, ownership conventions, and privilege protection baked in.
So paywall bypasses and data leaks are structurally impossible.
So you're never more than one step away from a working, auditable system.
The result? Clean builds from the start. Fewer bugs. Less debugging. Faster launches. And when you do run the QA audit, you pass — because the foundation was solid from day one.
How to Get the QA Skill
The Vibe Coder QA Skill is available now. It's the same rubrics-based audit method I used to discover the nightmares in my own app — refined, packaged, and ready for your project.
Go to app.johnnybodegas.com.
Create an account.
The QA Skill is included with your access — call it inside Claude Code, Lovable, or wherever you build.
No upsells. No hidden costs. Just the exact audit framework that saved me from launching a broken product.
The Real Cost of "Almost Done"
I spent $248 and 40+ hours learning that "90% done" is the most expensive lie in vibe coding.
The UI is the easy part. Any tool can generate a beautiful interface. The hard part is the part you can't see — the permissions, the error handling, the data integrity, the edge cases that only show up when real money and real users are involved.
If you're vibe-coding right now, stop. Not forever — just long enough to audit what you've built.
Run the QA. Check the rubric. Find the holes before your users do. Because the difference between a demo and a business isn't the UI. It's whether the thing works when it matters.
And trust me: you don't want to find out it's broken from an angry customer. You want to find out now, in private, with time to fix it.
What's Next
The next blog in this series: "The Clean Build — How I Rebuilt Dream App Hub From the Ground Up, Passed the QA, and Got It Ready for Real Payments."
I'll walk through the exact fixes, the lessons learned, and how the Copilot Architect approach changed everything. No more nightmares. Just a solid foundation.
Subscribe or check back — I'll post it when the build is live and the first real payment goes through.
Resources
What I built out of this, and the post that started the resilient-systems thread:
What Are You Most Worried Is Broken?
If you're vibe-coding an app right now, drop a comment: what's the one thing you're most worried is broken but you haven't checked yet?
The difference between a demo and a business isn't the UI. It's whether the thing works when it matters.
— Johnny Bodegas, a developer who spent $248 learning that pretty isn't the same as done.