Lovable, Bolt, v0, Replit, Cursor and Claude Code are genuinely good at this. A working prototype in a weekend is not a trick — it's a real app, and getting to one used to take a month.
The gap isn't between a prototype and a real app. It's between an app that works when you use it and an app that holds up when strangers do. Those are different bars, and nothing in the build process tells you which one you've cleared.
Veracode's 2025 GenAI Code Security Report found that 45% of tested code-generation tasks produced code containing a known security weakness. Not a comment on any one tool — the point is that working code and safe code are separate questions.
The five checks, in order
This is the order we work in, and it's ordered by what actually goes wrong first, not by what's easiest to fix.
1. Are your keys where a visitor can read them?
First because it's the most common, the most expensive, and the fastest to check. Everything your app sends to a browser is public. If your OpenAI or Stripe key went out with it, anyone can use it and the bill is yours.
2. Can one customer see another customer's data?
The one that ends businesses rather than costing them money. Test it directly: make two accounts, put something in the first, sign in as the second, and try to reach it — by changing the number in the web address, not by clicking around the interface. Clicking around only tests the buttons you were given.
If you're on Supabase or Firebase, this is what row-level security rules are for, and they are off, or wide open, in a lot of generated projects. The app works perfectly either way while you're the only user.
3. Does the server check who's asking?
A sign-in screen that hides buttons is not a sign-in check. The question is whether your server refuses the request when it comes from someone who isn't allowed — not whether the interface offers it. Anyone can send a request to your server directly; the browser is a convenience, not a gate.
4. What happens when something breaks at 2am?
Right now, most likely: nothing. Nobody is told, nothing is recorded, and you find out when a customer emails — if they bother, which mostly they don't. Error reporting takes about an hour to add and changes what running the app feels like more than anything else on this list.
5. Can you get your data back?
Not "is it hosted somewhere reputable" — can you produce a copy of your database today, and have you ever restored one? An untested backup is a belief about a backup. This is also worth asking about the platform itself: can you export the code and run it elsewhere, or does the business live inside someone's editor?
What you don't need to do
You almost certainly don't need a rewrite, and anyone who opens with one is selling their preference. Generated code is often untidy — duplicated logic, odd naming, components doing three things — and untidy is a maintenance cost, not a risk to your customers. It can be cleaned up incrementally, later, by anyone.
The five above are different. They're the ones where the app looks completely fine and isn't, which is precisely why they need someone to go and look.
Doing it yourself
Genuinely worth trying. Check one and check two you can do this afternoon with the steps above. Three, four and five need someone comfortable reading server code — a contractor for a day is a reasonable way to buy that, and so is asking whoever you'd hire next to do it as a first task.
What you shouldn't do is put it in front of customers and find out that way. That's the version where the cost lands on people who trusted you.