QWE AI Academy End state first: a tiny SaaS that signs users in, stores their data under row-level rules, and accepts a real Stripe subscription – not a mock checkout. That’s what working vibe coding SaaS looks like when it leaves the demo. Everything below walks backward from that outcome so you don’t ship a pretty shell that silently drops payments.
February 2025: Andrej Karpathy names the style – describe outcomes in plain language, let the model write, run it, paste errors back, stop owning every line. MIT Technology Review covered the coinage; Collins made “vibe coding” Word of the Year for 2025. For SaaS the loop still works. Until auth, webhooks, and multi-tenant rows show up.
Quick context: two tracks, one goal
Browser builders (Lovable, Bolt.new, Replit Agent) hand you a full stack in chat with hosting attached. Editor agents (Cursor, similar local setups) drop files on your machine so you own deploy and secrets.
Turns out the price rungs sit close together as of late 2026. Lovable’s pricing: Free is 5 daily build credits (capped around 30/month) plus small Cloud/AI grants; Pro from $25/mo for 100 monthly credits. Cursor keeps Hobby free with limited Agent use; Individual from $20/mo. Bolt’s paid rung also opens near $25/mo with a larger token pool (verify on Bolt pricing – token caps move).
Pick one track for the first product. Mixing mid-build burns credits and context.
Hands-on: vibe coding SaaS from the finish line backward
Target: email/password or magic-link auth, one protected dashboard, Stripe Checkout + customer portal, webhook that updates entitlement. Reverse the usual tutorial order.
1. Lock the finish line before any prompt
Half-page brief. Who pays. One job. Three screens. Exact success check: “test card completes; webhook flips plan to pro; second user cannot read first user’s rows.” No UI adjectives. If you cannot write that check, the model will invent a demo that only looks paid.
2. Force a plan, then one vertical slice
Paste the brief. Ask for a plan only – zero code. Cut scope until slice one is auth + one table + one paid gate. Then:
Implement only: Supabase (or built-in) email auth, profiles table with user_id FK,
RLS so select/insert/update require auth.uid() = user_id, and a /app route
that redirects unauthenticated users. Do not add billing yet. Done means:
sign-up, sign-in, protected page load, and a second account cannot see the first's row.Run it. Click every path yourself. Only then ask for Stripe.
3. Billing as a separate, testable loop
Checkout + Customer Portal + webhook next. Non-negotiable: signature check on the raw body, unique stripe_event_id, map checkout.session.completed / customer.subscription.* onto profiles, never trust the client for plan state.
Pro tip: After the AI claims webhooks work, fire the Stripe CLI or dashboard “resend” twice on the same event. Two entitlement rows or two emails means the handler is not idempotent. Fix that before live cards.
- Register the live webhook URL and secret in the host env (Vercel / Lovable Cloud / etc.), not only local
.env. - Live-mode price IDs in production; test IDs left in the client bundle are a classic silent fail.
- Service-role keys off the browser path. RLS on the user client; admin client only in webhook/cron routes.
Order that sticks: brief → plan → auth slice → billing slice → double-delivery test. Not “build me a SaaS.”
Common pitfalls that kill vibe-coded SaaS
AI PRs are messier than they look. CodeRabbit’s read of 470 real pull requests put AI-authored changes at about 1.7× more issues overall and roughly 2.74× more XSS than human PRs, with elevated improper password handling and insecure direct object references. Security task tests cited alongside that work (Veracode, Spring 2026) still saw models produce secure code on only ~55% of tasks without security-specific guidance. “It runs” is incomplete.
- Webhook body parsing: Generated handlers often call
request.json()first. Stripe signs raw bytes; re-encoding breaksconstructEvent. Read text/raw, verify, then parse. - Auth theater: admin/user flags and session tokens in
localStorage, no RBAC, no audit log – passes a solo demo, fails the first enterprise questionnaire. - Silent payment loss: missing retry/idempotency looks fine in your UI while subscribers never get access – or lose it after a failed renewal.
- God tables / no indexes: fine at 5 users; timeouts and host bills climb after that.
None of that shows in a happy-path screenshot. It shows in Stripe’s failed-webhook list and in security review red flags.
Funny thing about “shipped”: a lot of these apps still live on the platform subdomain like a temporary lease. The rent is low. The signal to customers and to payment processors is lower.
What the numbers say about results
Only 7.6% reported any MRR. That is the uncomfortable headline from BigIdeasDB’s September 25, 2026 Stripe Index / TrustMRR slice: 540+ businesses still taking Stripe payments from vibe-coding platform subdomains (Vercel, Lovable, Base44, Netlify, Replit, Bolt). In the revenue-verified subset still on those hosts, 0% cleared $1k MRR in the window; highest observed sat around $155. Shipping is cheap. Treating a free subdomain as a revenue plan is not.
Speed is real for validation. Real SaaS still needs a custom domain, owned database, spend caps on every metered API, and a human pass on auth and money paths.
When NOT to vibe-code the whole SaaS
Regulated data. SOC2-ready audit trails on day one. Enterprise buyers who inspect session storage and RBAC. A large existing codebase the agent will thrash. Skip pure vibe mode there.
Also pause if the “product” is a generic wrapper a model vendor can ship as a feature next quarter. The verified revenue pattern favors boring, specific workflows over another AI calculator.
If you cannot explain why a webhook is safe, are you ready to charge cards with it?
FAQ
Do I need to know how to code?
No for a Lovable/Bolt prototype. Yes the moment live payments or other people’s data appear – you have to break the flows on purpose.
Lovable or Cursor for a paid micro-SaaS?
Non-technical founder validating one idea: Lovable or Bolt can reach a clickable demo in a day. Export or rebuild the money paths before you market it. Want a real repo and long-term control? Cursor on a small Supabase + Stripe boilerplate. Browser tools win the first 48 hours; local agents win when platform defaults get in the way.
Why did checkout work in test but fail for real customers?
Usually: test price IDs still in the production bundle, webhook secret missing from host env, or body parsed as JSON before the HMAC check. Resend from Stripe’s dashboard. Watch server logs – not the success page.
Next action: open your tool, paste a half-page brief for one paid vertical slice, demand a plan with no code, implement auth only. Do not touch Stripe until a second test user is blocked from the first user’s rows.