The $87,500 prompt that was never written

A founder built his entire startup with Claude Code. Designed the interface, connected Stripe, set up the database. Everything worked. Tests passing. Clean UI. Product ready to ship.

He shipped it.

Hackers found the Stripe API keys sitting in the frontend code — visible to anyone who opened the browser’s developer tools. They charged $500 to 175 customers. $87,500 in fraud. Plus $2,500 in Stripe fees the founder had to eat.

The fix was one line: “Make sure all API keys are not on the front end.”

The founder, Anton Karbanovich, put it simply: “I trusted it too much.”

What’s notable isn’t that the AI failed. It’s that it didn’t fail. The code compiled. The Stripe integration worked. The app did exactly what it was asked to do. The problem wasn’t what the AI built — it was what nobody asked it to check.

Your MVP feels smarter than it is

AI-generated code creates false confidence. It compiles, it runs, the UI looks professional, tests pass. The founder sees a product. An experienced engineer sees a prototype.

Alex Turnbull, who documented Karbanovich’s case, described the pattern we’re seeing repeat: the MVP works beautifully in testing. Real users arrive with real edge cases. Security holes, scaling failures, and integration breakdowns surface that nobody anticipated. Rebuilding costs more than doing it right from the start.

In our experience at IQ Source, this pattern has accelerated since vibe coding tools matured. The gap between “works on demo day” and “works in production” hasn’t shrunk — what happened is it became harder to see because the demos got much better.

An AI-generated MVP can look indistinguishable from a professional product. What you don’t see is what matters: how it handles errors, what happens when two users do the same thing at once, where secrets live, what happens when someone tries to break it.

This isn’t about AI being bad. It’s about confusing velocity with readiness.

AI answers what you ask, not what’s missing

The best analogy we have: AI is a brilliant intern with no professional judgment. It does exactly what you ask, competently. It never says “wait, did you think about…?”

A senior engineer would look at API keys in frontend code and say “absolutely not.” The AI puts them there because you asked for a working Stripe integration. And it works.

There are entire categories of questions the AI won’t raise on its own:

Attack surface

Where are the secrets? Who can access what? What happens if someone reads the client-side code? These questions require a threat model that AI doesn’t build on its own — it answers if you ask, but doesn’t flag what you forgot to ask about.

Failure modes

What happens when the payment API goes down? When two users hit the same endpoint at the same time? When someone sends malformed data? AI generates the happy path unless you specifically ask for the sad paths.

Adversarial thinking

An experienced engineer looks at every endpoint and thinks about how an attacker would exploit it. That mindset — stepping into the shoes of someone trying to break your system — is something AI tools don’t apply by default. And it extends to the operational side: who gets paged at 3 AM, where the logs are, and how to roll back. These are questions only someone who has operated production systems knows to ask.

The gap isn’t in the AI’s capability. It’s in the founder’s ability to ask the right questions.

The questions nobody asked

This isn’t a generic checklist. These are specific questions tied to the Karbanovich case and similar patterns we’ve seen:

“Where are the Stripe credentials in this code?” — would have found the frontend API keys. A 30-second search.

“What can a user see if they open the browser’s developer tools?” — would have revealed the exposed secrets. It’s the first question any web security auditor asks.

“What happens if someone copies this API key and makes calls from outside our app?” — would have triggered the conversation about rate limiting, server-side proxies, and domain restrictions.

“What’s the worst thing that can happen if this code ships as-is?” — adversarial thinking. The question the AI won’t ask unless you prompt it.

In our experience at IQ Source, the questions that prevent incidents aren’t obscure technical knowledge. They’re the “what if” questions that come from having watched things go wrong before. The value of a senior engineer isn’t that they write better code — it’s that they know what to ask before the code ships.

For a more complete checklist of vibe coding risks, we wrote a detailed analysis in Open-Source AI and Vibe Coding: Risks Your CTO Is Ignoring.

The math: asking before vs. finding out after

Karbanovich’s numbers are concrete:

• $87,500 in fraud (175 customers × $500)
• $2,500 in Stripe fees
• Reputation damage with 175 customers who probably won’t trust the platform again
• Time spent on incident response, customer communication, Stripe disputes

How much does a security review before launch cost? Between $3,000 and $8,000 USD for a focused audit of critical modules: authentication, payments, personal data. We break this down in our analysis of AI code security.

$5,000 in review vs. $90,000 in losses — and that’s before counting the customers who never come back.

Security audits are the floor, not the ceiling. What most AI-built MVPs are missing is someone in the process who asks the questions the founder doesn’t know to ask. That can be a fractional CTO, a technical advisor, or an engineering partner with experience. What it can’t be is nobody.

The best AI-generated code still needs human eyes that say: “this works, but did you think about this?”

If nobody has tried to break it, it’s not ready

We write code, yes. But where we actually make a difference is sitting down with a founder before launch and asking what their AI never asked.

We’ve reviewed MVPs that looked production-ready and had payment credentials wide open. That kind of problem isn’t found by writing more code — it’s found by someone who already knows where to look.

For another angle on the prototype-to-production gap, our analysis of YouTube Recipes vs. Professional Software Development breaks down why “it works on my machine” isn’t the same as “it works.”

About to ship something built with AI?

If you haven’t asked someone to try to break it first, that’s the time to talk. We can do a focused review of your code before it hits production — and ask you the questions your AI didn’t.

Let’s talk before your code hits production →