Skip to content

"Zero hand-written code": the SaaS that was attacked two days after launch

On 15 March 2025 a founder posted on X that his SaaS was built with Cursor with zero hand-written code, and that people were paying for it. On 17 March he posted that he was under attack: API keys maxed out, users bypassing the subscription, and random data being created in his database. Within days he announced he was shutting the app down because fixes kept breaking other parts of the code. None of the attacks were sophisticated. Each maps to a basic check that takes minutes to run before launch.

By VibeGuard Team4 min read

On Saturday 15 March 2025, a founder who posts as leojr94_ on X shared a screenshot and a line that went around the internet: "my saas was built with Cursor, zero hand written code". He added that AI was no longer just an assistant but the builder, and that yes, people paid for it.

On Monday he posted again. He was under attack. His words: "maxed out usage on api keys, people bypassing the subscription, creating random shit on db". He said he wasn't technical and that fixing it was taking a long time.

By 20 March he had announced he was shutting the app down. Cursor, he wrote, "just keeps breaking other parts of the code", and he shouldn't have deployed unsecured code to production. He planned to rebuild on Bubble.

It's easy to make fun of this, and a lot of people did. It's more useful to read his three complaints as a checklist, because they're the three things that go wrong in most AI-built apps, and none of them needed a skilled attacker.

1. "Maxed out usage on API keys"

The app used paid services. Somebody found a way to use them on the founder's account. That happens in one of two ways.

The key is in the browser. AI tools often put a provider key where the frontend can read it, because that's the quickest way to make a feature work. Anything that ships to the browser is public. Anyone can open the page source or the network tab and copy it.

Or the key stays on the server, but the endpoint that uses it is open to anyone. If your app has a route that takes a prompt and calls an AI model, and that route doesn't check who's asking or how often, a stranger can call it in a loop. Your key never leaves the server and still gets drained.

The check: search your deployed site's JavaScript for anything that looks like a key (strings starting with sk-, sk_live_, or words like secret and token). Then list every route that costs money per call and confirm each one requires a signed-in user and has a limit on how often one user can call it.

2. "People bypassing the subscription"

This one almost always means the app decided who had paid in the browser. A flag like isPro stored in the page, a hidden button that only needs un-hiding, or a premium API route that assumes only paying users will find it.

The browser belongs to the user. They can change anything in it. A paywall has to be enforced on the server, based on a payment record the user can't edit, ideally one written by your payment provider's webhook after a real charge.

The check: create a free account, then try to use one paid feature directly, by calling the route it uses rather than clicking through the UI. Ask your AI tool to show you the request the paid feature makes and replay it as the free user. If it works, your paywall is decoration.

3. "Creating random shit on db"

Strangers were writing to his database. So the database accepted writes from people who shouldn't have been able to make them, which on the common AI stacks usually means missing access rules on the tables. We covered the same root cause in the Moltbook breach and in the 170 leaking Lovable apps.

The check: two test accounts, A and B. As B, try to read, edit and create rows that belong to A. Then sign out entirely and try to create a row using only the public key. Every one of those should fail.

4. The one he didn't list: fixes breaking other things

His final post is the most honest part of the story. When he asked Cursor to fix the security holes, it broke other features. That's normal. Security fixes change who's allowed to do what, and code that assumed "everyone can do everything" stops working once that changes.

That's why it's much cheaper to do this before launch. After launch you're fixing under pressure, with real users hitting the broken parts, and every fix can open a new hole. A 2025 study that asked models to "improve" the same code over and over found critical vulnerabilities went up by 37.6% after five rounds, which fits what he described.

What to take from this

Building an app entirely with AI isn't the mistake here. Plenty of people do it well. The mistake was going public, loudly, before anyone had looked at the app the way a stranger would.

A post that says "built entirely with AI" is an invitation to exactly the people who know where AI-built apps are weakest. You don't have to stop posting. Just run the four checks first. They take an afternoon, and all four are in our free pre-launch checklist.

Questions founders ask

Does posting about my app on X or Reddit make it a target?

It brings attention, and some of that attention will be curious people poking at your app. That's not a reason to stay quiet. It's a reason to run the basic checks before the post goes out, because your first traffic spike is also your first security test.

How can someone bypass a subscription paywall?

Usually because the app decides who has paid in the browser instead of on the server. If the page checks a flag like isPro that the user's own browser holds, the user can change it. The check that unlocks paid features has to happen on the server, based on data the user can't edit.

What does 'maxed out API keys' mean?

Someone found the app's key for a paid service, such as an AI model provider, and used it themselves until the usage limit or the bill ran out. This happens when the key sits in the website's code or when an endpoint calls the paid service with no login and no rate limit.

Sources

  1. Original post: 'my saas was built with Cursor, zero hand written code' · X (@leojr94_), 15 Mar 2025
  2. "Vibe Coding" vs Reality · Cendyne, 19 Mar 2025
  3. Security Degradation in Iterative AI Code Generation · Shukla, Joshi, Syed (arXiv), 19 May 2025
  4. Post announcing the shutdown · X (@leojr94_), 20 Mar 2025

Is your app one of them?

An independent security check of your live app, from €59, with fix prompts for the coding tool you already use. Read-only, and it never touches your code.

Check my app

Keep reading

All articles