I've built a handful of small apps and client prototypes with Bolt.new over the last year. Type a sentence, watch it build, deploy before lunch. That speed is the entire pitch, and it holds up.
What I didn't think about for a long time was everything that happens between typing the sentence and the app actually going live. Nobody in a demo video stops to talk about database permissions.
What ships by default now
Bolt.new, built by StackBlitz, launched in October 2024 off a single tweet and reportedly hit four million dollars in annualized revenue within its first month. Since then, two security features have quietly become part of the default experience, not something you have to go looking for in a settings menu.
The first is leaked-password protection, added around mid-2025. If you build a sign-up flow with Bolt, it checks the password a new user picks against known breach databases before letting them use it. That's not a new idea on its own, plenty of platforms have done this for years, but it's a real win here because it protects people who never would have thought to add that check themselves.
The second landed by October 2025: a broader automatic vulnerability check that runs at the moment you hit publish. Before the app goes live, it gets scanned. The exact rule set behind that check isn't public, but the timing is the useful part. It happens at the one moment a builder is least likely to be thinking about security, which is right before shipping, when the only question on their mind is whether the thing works.
Both of these ask nothing of the person building the app. No changelog reading, no knowing what row-level security even means. That's the right shape for a tool built for people who are not security engineers, which is most of the people building with it.
What's still on you
None of that changes the basic limit of an automatic scan: it catches known patterns, not your specific logic.
The incidents that made headlines across AI app builders in 2025 weren't exotic. Lovable disclosed a row-level security flaw in May 2025 that had left database records open across a large number of apps built on it. Base44 had an authentication-bypass bug, reported by security researchers that July, that let anyone register into a private app using nothing but a public app ID. A scan can flag "this table has no access rule" if it's built to look for that exact shape of problem. It can't know that your app's real security boundary is "only the account owner should ever see this row," because that's your business logic, not a pattern sitting in someone else's rule file.
That's the honest baseline for anything an AI tool writes for you right now, automatic publish-time checks included. A scan at the moment you ship is real progress over nothing. It is not proof the logic underneath is sound.
So the practical list doesn't shrink much just because the tool got better: know what your database actually lets anyone read or write, keep service keys out of anything that ships to the browser, and check that every route which is supposed to require login actually rejects a request without one. None of that shows up in a demo. All of it shows up in an incident report.
The pause built into the button
The thing I keep noticing is that the publish button is doing two jobs now. It ships the app, and it's also the one moment the tool itself stops to check it. That's worth using on purpose. Not by clicking past the scan result, but by treating that pause as your own cue to ask the boring questions before the app goes public: who can actually read this table, what happens if this endpoint gets hit without a token, where did that key end up. The tool checks its own list. The rest is still yours to check.