You Built an App With AI. Who Checks It Before Real Users Show Up?

Somewhere on your laptop there's an app you built with Claude Code, Cursor, or Replit, and it works. You've clicked through every screen, the demo went down well, and people keep asking when they can use it. Under all that excitement there's a quieter question, and it's one you can't really answer on your own: is it safe to put in front of strangers?

Vibe coding got you here, and that's not the problem

First, credit where it's due. If you've built a working product without a development team, you've done something that wasn't possible three years ago, and you're in good company. For a quarter of Y Combinator's Winter 2025 batch, 95% of the code was written by an LLM, according to YC managing partner Jared Friedman (TechCrunch). These are funded companies with revenue, so they're well past the hobby stage.

So the build itself is fine. The trouble comes after, and it's down to something quite simple. When you test your own app, you test the happy path: the signup that works, the upload that succeeds, the route you designed. It's the only path you know to test, because it's the only one you can see. An attacker tries every other path, like a broken file, a request sent straight to your API without touching the screens, or the password reset hit five hundred times a minute. Your app has never met visitors like that, and neither have you.

The gaps don't show up until someone goes looking

This isn't scaremongering, and the research on AI-generated code keeps coming back with the same answer.

Veracode put more than 100 language models through 80 coding tasks and found that 45% of the generated code introduced security flaws from the OWASP Top 10, the industry's standard list of the most serious web vulnerabilities. For cross-site scripting, the failure rate hit 86% (Veracode). What worried us more than the headline number was that newer, larger models did no better than older ones, so you can't expect the next model release to quietly fix security for you.

Wiz, the cloud security firm, looked at what happens when those apps reach production. Their researchers found roughly 1 in 5 organisations building on vibe-coding platforms exposed to risk through the same recurring misconfigurations (Wiz). Authentication was handled entirely in the browser, with passwords readable by anyone who opens the page source. Database access rules were left wide open or never switched on, secrets were pasted straight into the code, and internal tools sat on the public internet, where the automated scanners that sweep it constantly could find them.

Have a look at what's on that list. There's nothing exotic in it, just the well-known mistakes that bots find on their own, and they keep turning up for an understandable reason. The model writes whatever is typical of the public code it learned from, and it carries none of your liability. Meanwhile it's very hard for you to review code you can't read, in the same way nobody can proofread a language they don't speak.

What a vibe code review actually is

A vibe code review is a focused pass over your codebase by a senior engineer, who reads it the way an attacker would and then the way your next hire would. It takes days, and we won't rewrite your app or lecture you about how you should have done it. We build with Claude Code ourselves every day, so what we want is to help you keep the speed you've gained and add the safety you're missing.

The pass covers six things. Security comes first: the OWASP Top 10, your authentication flows, input validation, and anything secret that's ended up somewhere public. Then we look at how the app is deployed, including environment configuration and how keys and credentials are stored, and at the dependencies it's built on, since AI tools happily import packages with known vulnerabilities. We check what happens when more than five people use it at once, and whether errors are handled, logged and backed up, or just silently swallowed. Last of all we look at the code itself, and whether the next developer, or your own next AI session, can work in it without breaking it.

You get the findings as a plain-English report, ranked from what's dangerous down to what's just untidy, and we'll have a call to walk you through it. If you'd rather we fix things for you, the Production Ready tier covers hands-on remediation, deployment, monitoring, and handover documentation.

How it worked for Pactora

Sneha Ganapavarapu spent six years as a commercial lawyer before moving into product. The recurring waste she kept seeing, contracts queuing for legal review when most of the risk could be triaged earlier, became Pactora: an AI contract reviewer that flags risky clauses, scores how exposed they leave you, and hands back the fallback positions and redline wording to negotiate with. She built it with Claude and Claude Code, as a non-developer (vibecode.law).

Think about what that app does for a moment. Strangers upload contracts to it, which are commercially sensitive agreements full of names, terms, and money. A public file upload that handles confidential documents is about as review-worthy as an AI-built app gets, and to Sneha's credit, she treated it that way before launch instead of after an incident.

Our review focused on the parts of the app that anyone on the internet can reach. We added CSRF protection, baseline security headers, and rate limiting on the open endpoints. We also protected the file upload against the nasty stuff, such as files pretending to be a format they aren't, and compressed uploads built to expand until they take the server down. After that we stayed on as a sounding board for tooling and product direction.

In May 2026, Pactora took the number one spot on the vibecode.law leaderboard, the showcase platform for legal professionals building with AI, and it holds its number one lifetime rank. We want to be fair about the credit, because Sneha built the product and the win is hers. Our part was smaller. When a leaderboard win sent a wave of curious lawyers, journalists and, inevitably, a few probing bots its way, the app needed to hold up, and it did.

When to book one, and when not to bother

Not every AI-built project needs this. If you've made a tool for yourself, it touches nothing sensitive, and nobody else uses it, carry on and enjoy it. The review becomes worth it the moment any of the following are true:

1. Strangers are about to use it. Launch, beta list, a Product Hunt or showcase entry that could spike traffic overnight.
2. It handles other people's data. Accounts, uploads, anything personal. UK GDPR doesn't care that an AI wrote the code.
3. Money moves through it. Payments, subscriptions, anything with a card form.
4. Someone's about to scrutinise it. Investor due diligence, or a B2B customer sending over a security questionnaire you don't know how to answer.
5. You're about to build on top of it. Foundations are cheapest to fix before the next six months of features land on them.

The best time is just before real users arrive, but if they're already using it, now is still a good time.

The part you can't vibe your way through

Vibe coding made the build much quicker, but it can't give you the scar tissue, which is the judgement an engineer builds up over years of watching production systems fail in surprising ways. A review lets you borrow that judgement for a few days, so you don't have to learn it one incident at a time with your users' data paying the price.

You've already done the hard, creative part. If you'd like a second pair of eyes on it, book a review and we'll help you get it ready for real users.

---

References

• We Asked 100+ AI Models to Write Code. Here's How Many Failed Security Tests. (Veracode)
• Wiz Research Finds Risks in 20% of Vibe-Coded Apps (Wiz)
• A quarter of startups in YC's current cohort have codebases that are almost entirely AI-generated (TechCrunch)
• Pactora on vibecode.law
• vibecode.law
• Pactora