I checked 3 SaaS products built with Cursor this week. All 3 had the same silent billing bug.
I have been doing something obsessive for the past two weeks.
Every time I see someone tweet "just shipped my SaaS". I open their site, view the page source, and look at their Stripe setup.
Not to judge. Just to understand.
What I found scared me a little.
All three founders I looked at closely this week had the exact same issue. Their webhook handler catches Stripe events. Returns 200 OK. Stripe marks it as delivered and moves on.
But inside the handler, nothing actually happens.
The code logs the event. Returns the response. And exits.
No access revoked. No subscription updated. No database touched.
So when a payment fails, Stripe sends invoice.payment_failed to their endpoint. Their server says "got it." Stripe believes it. The user keeps full access to the product.
Forever.
None of these founders knew. Their Stripe dashboard showed payments coming in from other customers. MRR looked fine. Everything felt normal.
The leak was invisible because it only shows up at the intersection of two things, who failed to pay in Stripe, and who still has active access in their database. Neither system flags the overlap automatically.
I am not posting this to make anyone feel bad. I shipped broken billing code myself before I understood this.
I am posting this because I genuinely think this is the most common hidden bug in AI-generated SaaS right now. Cursor and Lovable are incredible at building the happy path. Checkout works. User gets access. Everything looks fine.
The failure paths, payment fails, subscription cancels, refund issued, these are the parts AI tools generate poorly because the tutorials they learned from skip them.
If you built your SaaS with an AI tool in the last year, go check one thing right now.
Open your webhook handler. Find the case for invoice.payment_failed. Look at what is actually inside it.
If it logs and returns without touching your database or your user's access state, you have this bug.
Happy to help anyone check theirs. I have been doing free manual audits this week using just a restricted read-only Stripe key. Takes me about 45 minutes. I send you a report showing exactly what I found with real event IDs you can verify yourself.
No pitch. Just trying to understand how widespread this actually is, and help a few founders find out before it compounds further.
Drop a comment if you want me to check yours.
Reading this made me immediately check my own webhook handler. Pretty sure a lot of us shipped something similar without realizing it
That instinct to check immediately is exactly right. The tricky part is knowing what to look for when you open it, most handlers look fine until you trace what actually happens to user access after the event fires.
Data in the ad library can be very noisy. ~
You might seem to have found something golden but when you look to actually use it, much of it is noise, it won't help you optimize any further. For instance, many take the sheer quantity of ads a brand is running and draw conclusions. This can be the opposite.
If a brand is running tons of ads it could either be doing incredibly well and is saturating the market, or it's running a ton of bad experiments, wasting cash and making terrible decisions.
More useful, is what stays live, what gets repeated, and if there is logic behind what they are doing. Are the same core concepts still running weeks out? Are they reusing the same messaging with different locations? Do they seem like they are identifying what is working and going double down? These are all more useful concepts than raw numbers.
If I were to build this feature, I would make it simpler for users to identify high impact opportunities and not just add another list of more data; most users don't want more stats, they want more clarity on where to look.
Also some of the greatest products will not show up on an ad library at all because their strength is derived on the back end after the user clicks, where they come back, spent more and continues to buy over time.
Exactly, volume creates the illusion of insight.
What actually matters is what survives over time and drives decisions, not just what shows up once.
This is honestly both surprising and a bit scary.
It’s the kind of bug that doesn’t break anything visibly, but quietly leaks revenue in the background.
Makes me wonder — is there any automated way to audit this, or is everyone just manually checking their Stripe webhooks?
That is exactly what I am building Revlo. Right now doing manual audits to understand the patterns before automating them. If you want me to run one on your account this week it is free. Just need a restricted read-only Stripe key
This comment was deleted 2 days ago.
"This is a massive wake-up call for everyone using 'vibe coding' to ship fast. That 200 OK response from a hollow webhook is exactly the kind of technical debt that kills a SaaS once it scales. Thanks for the heads-up on the invoice.payment_failed logic—definitely something to double-check in the repo today.
For the founders you're auditing, once they've patched those leaks, they should definitely enter this competition-This might sound interesting 👇
You have an idea
$19 entry
🏆 Tokyo trip + hotel
💰 $500
Round just opened 👉 tokyolore.com
The scary part is not the bug.
It’s that everything looks “fine” while it’s happening.
Silent failures like this are way more dangerous than obvious ones.
Exactly, obvious bugs get fixed, silent ones get normalized.
That’s how small leaks turn into real revenue damage over time.
That’s the worst part.
By the time you notice it, the damage is already done.
Spot on, Harsha. I am seeing the exact same pattern, but on the infrastructure side.
I recently audited 279 AI-built SaaS products and 64% had critical exposure. Like you said, tools like Cursor and Lovable are incredible for the 'happy path', but they are terrible at perimeter defense and edge cases. While they leave billing loopholes on the backend, they are also leaving API keys exposed in JS bundles and DNS wide open for email spoofing on the outside.
The AI builds the house fast, but forgets to lock the doors.
Love what you are doing here. It's a massive blind spot for founders right now. Keep it up!
That’s exactly it, different layers, same blind spot.
Everything looks production-ready, but the failure paths and edges are where things quietly break.
The "MRR looked fine" detail is the scary part. The dashboard shows incoming payments from paying customers and masks the leak completely. You'd have to specifically look at the intersection of failed payments and active access to catch it.
This is exactly why I built Autoreport — a weekly PDF with Stripe data every Monday, including failed payments, refunds, and disputes side by side with active customers. The bug you're describing would show up as a pattern: failed payment events with no corresponding access change. Not a full audit, but a weekly sanity check.
Going to review my own webhook handler after reading this. Built with Lambda + API Gateway, not Cursor, but the failure paths deserve another look.
Autoreport showing failed payment events with no corresponding access change is exactly the pattern. That weekly signal is valuable, what I do is go one level deeper and find the specific code gap causing it. These genuinely feel complementary. DM me, think there is a referral setup worth exploring.
Makes sense as a pairing — Revlo finds the gap, Autoreport keeps the signal visible week to week. Open to exploring the referral setup. I'm on X, same handle — let's talk there.
Tried to DM you on X but couldn’t message first. Feel free to reach out there, my handle is @getrevlo.
This is such an underrated issue.
What’s scary is it doesn’t break anything visibly — it just slowly erodes trust + revenue in the background.
Feels like most AI-built SaaS handle the “grant access” path well, but almost ignore the “revoke access” side.
Have you seen this more in simple Stripe setups, or even in slightly more structured systems?
Yeah, that’s exactly where it gets dangerous.
The more “structured” the setup looks, the easier it is to assume it’s handled when it’s actually not.
Yeah — and the scary part is founders don’t even realize it because everything looks “fine” on the surface.
Stuff like this really shows how much trust in a product isn’t just features — it’s all these invisible layers working correctly.
Also interesting from a positioning side — tools that deal with things like billing / infra / reliability almost need to feel solid and dependable upfront, otherwise people hesitate even if the product works.
Out of curiosity — are you thinking of turning this audit work into something more structured, or keeping it manual for now?
Yes, building it into a product. The manual audits are validation that the problem is consistent enough to automate. Hit rate so far is higher than I expected. If you want early access DM me.
That makes sense — validating it manually first is the right move.
This feels like something that could become core infra pretty fast.
Would love to try early access — what’s the best way to reach you?
DM me here on X my id is @getrevlo to get early access . Running free manual audits this week.
That’s a strong signal then — if the hit rate is already that high manually, there’s definitely something real underneath it.
One thing that stood out reading this is how these issues sit in that weird zone where everything looks “correct” technically, but the system behavior is still wrong.
Which probably makes them harder to productize than typical bugs — because you’re not just detecting errors, you’re detecting mismatches between systems that both think they did their job.
Curious how you’re thinking about that layer — is it more rule-based (specific event checks), or trying to model the expected state vs actual state over time?
Right now it is rule-based, specific event checks against expected downstream state changes. For each critical event type I check what should have happened within a defined window and flag the gap. The mismatch detection is simpler than it sounds because Stripe's event log is actually quite clean to query. The harder part you identified is exactly right though, both systems think they did their job. Stripe delivered the event. The server returned 200. The gap lives entirely in what happened between receiving and processing. Long term the interesting layer is modeling expected state over time — but for MVP the rule-based checks catch the highest value gaps consistently. Happy to walk you through the detection logic on a call if you want to go deeper.
Makes sense — that “both systems think they worked” gap is exactly where it gets tricky.
I can show you how I’m checking it — easier over a quick walkthrough.
I’m not active on X right now — are you on LinkedIn?
This comment was deleted 5 hours ago.
That "silent billing leak" is a terrifying thought for any founder—AI is great at building the "happy path" but notorious for ignoring the failure states like webhooks. Helping founders find these invisible MRR drains through manual audits is a high-value way to build trust in the community.
Since you're basically acting as a specialized auditor for these billing gaps, there’s a competition where you can submit this service or your own project—entry is $19 and the winner gets a Tokyo trip.
Prize pool just opened at $0. Your odds are the best right now.
When you're doing these audits, are you seeing this mostly with Stripe's hosted billing or custom-built access control logic?
How should we proceed?
Appreciate it, and yeah, this shows up more in custom access logic than Stripe itself.
Stripe does its job, but the gap is usually in how founders map those events to actual user access.
The framing of “AI tools generate the happy path, not the failure path” is the cleanest summary of the vibe coding risk I’ve seen. This should be a checklist item for every founder shipping with Cursor or Lovable. The free audit offer is generous. Curious if you’re planning to turn this into a product or service.
Appreciate that, the “happy path vs failure path” gap is exactly what keeps showing up.
Right now I’m mapping how widespread it is before deciding whether this becomes a product or stays a service. The patterns have been interesting so far.
In my experience, the "generate happy path" has been too common for human developers, so it's unfortunate that AI is not filling these gaps. I imagine this is going to be common as more code is vibed out until the ecosystem of LLM code has better examples to work with.
Exactly, AI just amplified an old habit, it didn’t create it.
The difference now is those gaps scale much faster, so the consequences show up sooner and hit harder.