Every AI app builder I've tried can spin up a login screen before you've finished your coffee. Clean form, nice validation, a satisfying little loading spinner. What I wanted to know was whether any of them would also remember the part that never shows up in a demo: the moment, weeks later, when a real user forgets their password and needs a way back in.
So I ran an experiment. Same prompt, same day, five different AI app builders, zero follow-up messages. I wanted to see what each tool considered "done" when nobody was there to ask for more.
The Setup
The prompt was exactly twelve words, and I counted them on purpose so nobody could argue I'd buried a hint in there: "Build a simple app where users can sign up and log in."
That's it. No mention of password reset, no mention of email verification, no mention of sessions or security. Just the sentence any non-technical founder would actually type into one of these tools on day one, because "sign up and log in" is how most people describe "basic auth" without knowing the term.
I tested five tools that all sell the same pitch: describe your app, get a working product. Lovable, Bolt, Replit's Agent, v0, and Base44. For each one, I pasted the prompt once, let it finish generating, and then tried to actually use what it built. I clicked every visible button, checked whether a "forgot password" link existed anywhere, and where I could see the generated code, I searched it for anything resembling a reset token, a reset endpoint, or an email-sending step.
Four out of five had nothing. Not a broken attempt at password reset. Not a placeholder. It simply never occurred to the tool that a login screen might need one.
What each one actually shipped
Lovable was fast and it was pretty. Under two minutes and I had a signup form and a login form with real client-side validation, animated error states, and a dashboard shell waiting behind the login. I looked everywhere a "forgot password?" link is conventionally supposed to live, under the password field, next to the submit button, in the footer. Nothing. Lock yourself out here and there is no way back in except signing up again with a different email.
Bolt produced something in the same spirit, arguably tighter on the styling side, with a slightly more convincing dashboard mockup behind the auth wall. Same story underneath. Working signup, working login, and the account recovery path simply doesn't exist. I opened the generated source to double check I hadn't missed a hidden route. There wasn't one.
Replit's Agent was the most ambitious of the four. It actually wired up a real database table for users instead of faking the auth state client-side, which is a meaningfully more production-shaped choice than what Lovable or Bolt did. Sign up worked, log in worked, sessions persisted properly on refresh. And still, nothing for reset. The closest it came was a generic "contact support" line sitting in the footer, which is not a password reset flow, it's a promise that a human will eventually deal with the problem the software should have handled.
Base44 was the fastest of the five, and the least surprising. A working auth screen showed up almost instantly, no reset flow, no email verification step either. It optimized hard for "looks finished the second you land on it," and on that specific metric, it won.
v0 was the one that broke the pattern. Instead of hand-rolling a custom auth UI, it scaffolded a proper Next.js project with NextAuth wired underneath, and the reset flow was actually there: a "forgot password" link, a token-based reset route, and a mocked email step that would send a real reset link once you dropped in actual SMTP credentials. It wasn't polished. The reset page had zero styling and looked like it had wandered in from 2015. But it was structurally complete in a way none of the other four attempted.
The scorecard
Lovable — Signup + login ✅ · Password reset ❌ · Email verification ❌ · Real DB-backed users ❌
Bolt — Signup + login ✅ · Password reset ❌ · Email verification ❌ · Real DB-backed users ❌
Replit Agent — Signup + login ✅ · Password reset ❌ · Email verification ❌ · Real DB-backed users ✅
Base44 — Signup + login ✅ · Password reset ❌ · Email verification ❌ · Real DB-backed users ❌
v0 — Signup + login ✅ · Password reset ✅ · Email verification ❌ · Real DB-backed users ✅
Why four out of five missed it, and it isn't really a bug
None of these tools are broken. Each one did exactly what it's optimized to do, which is turn a short sentence into something that looks finished on the first two screens a person actually sees. A signup form and a login form are the entire demo. Nobody records a screencast of clicking "forgot password" to show off a new app builder, so there's no pressure, competitive or otherwise, for that screen to exist.
There's a second, more structural reason underneath that one. Password reset isn't just a UI screen, it's a small distributed system: a token that expires, a database write to invalidate the old password, and an email that has to actually leave the building through a real SMTP provider or transactional email service. That last part requires credentials the AI builder doesn't have and can't invent. Signup and login can be faked entirely client-side if a tool wants to cut corners, which is exactly what Lovable, Bolt, and Base44 did. Password reset can't be faked the same way, because at some point a real email has to go somewhere. My guess is that's a meaningful part of why it gets skipped rather than half-built: there's no convincing way to fake it, so it's easier to just not mention it.
v0 sidestepped the problem by not trying to invent the wheel. Scaffolding a known library like NextAuth means inheriting whatever that library's maintainers already decided a complete auth system needs, reset flow included, even in a rough, unstyled, "you still have to plug in your own email provider" state. The other four built something closer to a bespoke UI kit than an actual auth system, and bespoke is exactly where the corners get cut.
None of this is really about the prompt being too short. A real build usually moves through discovery, scoping, and a hardening pass before anything reaches a user, and that's roughly the shape most production MVPs actually take, even the ones that come together fast. A single twelve-word sentence was never going to carry all of that on its own, which is exactly why it's worth checking what got left behind.
The part that should actually worry you
Password reset is just the gap that's easy to catch, because everyone already has an intuition for what a login screen is supposed to include. It's the visible tip of a much less visible problem.
None of the four also handled account enumeration, meaning I could tell from the signup error message alone whether a given email was already registered, which is a small but real information leak. None of them had rate limiting on the login form, so nothing was stopping an unlimited number of password guesses against any account. Only one reset a user's other active sessions after a password change, which matters a lot if the reason someone's changing their password is that they think their account's been compromised in the first place.
None of that shows up in a ninety-second demo either. It only shows up when you go looking for it, which is precisely the problem: most people don't go looking, they ship what the tool handed them.
This is close to what we keep running into at EnactOn whenever a founder hands us a prototype from one of these builders and asks us to take it into production. The parts that impressed them in the demo are reliably fine. The parts nobody clicked on are where the actual work is waiting. If you're leaning on one of these tools for something you intend to charge real users for, it's worth understanding where the genuine trade-offs sit before assuming "it worked when I clicked through it" means "it's ready for someone else to click through it too."
What to actually check before you trust the output
Don't just test the two flows the tool showed you. Go find the third one it didn't.
Forget your password on purpose and see what actually happens when you click through the flow, not just whether a link exists. Sign up with an email that's already registered and read the error message closely, since a message that confirms the account exists is a small gift to anyone running a credential-stuffing attack. Log in, change your password, and check whether a session you opened before the change still works somewhere else. Hammer the login form with wrong passwords a dozen times in a row and see if anything stops you, because in four out of five tools here, nothing did.
None of this takes more than twenty minutes to check by hand, and doing it before a real user finds the gap is a lot cheaper than doing it after. The broader shape of what these tools are actually good at, and where that speed runs out, is worth reading before you decide how far to trust the output of any single prompt. This is close to the actual checklist we run at EnactOn before we'll tell a founder their AI-built app is ready for a real user, and none of it is exotic, it's just the stuff a demo never forces you to check.
Every SaaS product that survives past its first hundred real users ends up going back and building this exact list eventually. The ones that made it look obvious in hindsight mostly just did it before launch instead of scrambling to do it after.
Has anyone else run one of these builders through a flow it didn't bother showing off, and found something missing?
Top comments (0)