The platforms — Lovable, Bolt, Replit, Claude Code — get a lot of grief from skeptics, and most of the grief is wrong. I use them all. My team uses them all. I've watched non-technical operators ship working software inside a weekend that would have been a six-month engineering project three years ago. The people sneering at these tools, almost always engineers whose discomfort is more about identity than craft, are going to look as silly in five years as the people who in 1998 said "real businesses don't run on the web."
This isn't a "these tools aren't real" piece. They are real. They're stunning. The piece I want to write is about the moment the thing you built crosses a line the tool wasn't designed to handle, and what to do about it.
That moment, in my experience, is roughly the third time someone asks you a question that starts with "what happens if…"
What happens if we lose the database. What happens if a release goes wrong. What happens if a customer hits a weird edge case where two things hit the system at once and the data goes sideways. What happens if an access key leaks. What happens if you go on vacation. What happens if Lovable changes their pricing. What happens if Bolt is acquired and their hosting story changes. Each of these is a perfectly reasonable question that the tool, by design, did not optimize for.
That isn't a tool problem. It's a maturity-threshold problem. The tools exist to compress time-to-first-working-version, and they're extraordinarily good at it. They don't exist to compress time-to-operationally-mature-system, which is a totally different game with totally different requirements. Asking Lovable to handle continuous monitoring, deploy safety, secret rotation, and disaster recovery is like asking your sketchpad to handle structural engineering. Wrong tool, wrong question.
What I want to do is share, plainly, what each of these tools does well and where the threshold tends to land.
Lovable is the fastest way I know of for a non-technical founder to ship a real interface against a real database. It's particularly good when the workflow is well-understood, the data model is fairly contained, and you don't have a lot of integrations. Where it tends to hit its threshold is when business logic complexity grows past what the prompt-based generation can keep coherent, when you need a real separation between the testing environment and production, or when you need to plug into a meaningful number of external systems with proper retry logic and protection against duplicate processing. None of those are deal-breakers. They're signals.
Bolt is similar in shape but lands a little differently — its strength is that it's closer to a real codebase from the start, which means the threshold issues tend to be operational rather than architectural. Bolt-built applications usually fail not because the code can't grow, but because the deploy story, the credential story, and the monitoring story were never set up.
Replit's strength is breadth. You can host pretty much anything in pretty much any technology. The threshold there tends to be about discipline rather than capability. Replit will let you ship fast, including fast in ways you'll regret. The cost of "I'll just deploy this from the browser" compounds over six months in ways most founders don't see until something breaks.
Claude Code is my personal favorite, and the threshold pattern is different again. Because it's giving you actual code in an actual folder on your actual computer, the platform-portability problem barely exists — the code is yours, in a repository you control, and the AI is just helping you author it. The threshold for Claude Code-built systems tends to be the same threshold as any custom-built system. At a certain operational scale, you need monitoring you don't have, deploy discipline you don't have, runbooks you don't have, and a real on-call story you don't have. The code is fine. The operations around it are missing.
The common thread across all of them: the tools optimize the part of the lifecycle that used to be hard. The part that's now hard — the operating side — they don't pretend to handle, and shouldn't have to.
Here's what I tell operators who arrive here. Don't move off the tool. The tool was never the problem. Take what you built, normalize it into a state that can be operated like real software, and then either keep operating it yourself with that scaffolding in place, or hand it to someone whose job that is. The thing that makes the system load-bearing is the same thing that makes you nervous about it. Don't downgrade the system to make yourself less nervous. Add the scaffolding the tool didn't ship with.
We do this for a living, so my advice is biased — but the bias is toward keeping the velocity you got from these tools, not killing it. The threshold isn't the tool's failure. It's the tool's success. The reason you're at the threshold is because the thing you built actually worked.