The 30% Your Replit or Lovable App Is Still Missing
By the Founderest team · August 16, 2026
Researchers at Columbia's DAPLab studied why AI-coded apps break, and put a number on how far these tools actually get you before something goes wrong: about 70%. Not 70% of the features you asked for. 70% of the way to something that survives an actual stranger using it.
Their own findings point to error handling and business logic, code that runs without crashing but quietly doesn't do what the user needed, as the most common and damaging failures, not security specifically. That's the other 30%. The checklist below, the kind a real engineer runs before calling anything finished, is real and worth checking. It's just this site's own addition to that gap, not DAPLab's headline finding.
What does that other 30% actually contain?
Here's roughly what's on that checklist, in the actual terms an engineer would use for it:
- Auth session invalidation on password change
- Rate limiting on public endpoints
- CORS locked to your actual domain, not left open to any origin
- Input sanitization against injection
- CSRF protection on state-changing requests
- Environment variables that aren't bundled into client-side code
- Database migrations that don't wipe existing rows
- Idempotent webhook handling
- Race conditions in concurrent writes
- Query patterns that quietly fall over once real traffic hits them
If none of that meant anything to you, that's the point. It's meant for whoever checks it, not for you to memorize. If nobody checks it, none of it goes away. It just waits. Then your site starts breaking in ways you can't explain, or worse, someone finds the gap first and walks out with your users' data.
Why does this list feel like it's in another language?
Because it is genuinely technical work, and a tool that writes code when you describe a screen doesn't automatically also audit what it wrote against that list. Those are two different skills, and most AI app builders only claim the first one. Translated into what actually happens to your app: CORS left open means any website can quietly read your users' data straight through your own API. No rate limiting means someone can write a script that guesses passwords on your login page thousands of times a minute, and nothing stops it. An environment variable bundled into client code means your payment provider's secret key is sitting in plain text in your users' browsers, visible to anyone who opens developer tools.
Security isn't one fix, it's a whole category of things to check. The items above tied to exposed secrets, injection, and open CORS are the same ground OWASP's Top 10, the industry-standard list of what actually goes wrong in web apps, covers. A single prompt can't close all of that, and asking a tool to “make it secure” gets you the same vague reassurance as asking a person to “be more careful.” Here's one specific, verifiable piece of it:
Vague prompt
“Make sure my app is secure.”
Too vague to act on. The tool has nothing specific to check, so it usually responds with reassurance instead of an actual answer.
Specific prompt
“Look through my code for any API keys, passwords, or secret tokens that are written directly in the code instead of stored as environment variables. List every file where you find one, and move each one to an environment variable instead. Then: - List every file you changed and every secret that was exposed. - Check whether that same key shows up anywhere else you didn't touch, like an old test file or a config file, since one leftover copy defeats the fix. - Verify that nothing else in the app breaks because of this change. - Check my commit history to see if any of these keys were ever committed and pushed. If they were, list which ones, since those need to be rotated even after you remove them from the code.”
You don't have to learn all of this yourself
You don't need to become the person who understands session invalidation. You need to be the person who makes sure something checks for it before real users show up, because “I didn't know to look” doesn't undo the damage once someone's password gets guessed or their data leaks through an open API. That's the actual job your advisor team does here: run this exact list against what you've built, in plain language, before it costs you something.
See why building without a plan gets founders stuck, or read what Founderest's advisor team actually does with a list like this one. Checking this list once isn't the end of it either; here's what usually breaks next, after real users show up.