Vibe-coding tools have been having a moment, and honestly the appeal makes a lot of sense. As a novice designer who's actually studying design right now, I've been pulled toward them the same way everyone else has - there's something genuinely interesting about watching a natural language prompt turn into a working interface. And the demographic is broad. Developers use these tools, people who've never touched a terminal use these tools, and somewhere in the middle is me, dragging design briefs into the chat to see what comes out.

I've tested a handful of them at this point. The architectures and features are different, even who they're built for is different. But after a good number of hours in each one, it became clear that they do share some of the same problems. And these aren't the bits anyone is really talking about. Most of the coverage I see leans heavily into how impressive these tools are at starting things, which they genuinely are. But things are a bit quieter on the finishing part. Here's why I'd think twice before getting too reliant on any of them…

You don't own what you build

Free tiers give you a tenant slot, not a home

I'll be upfront here - I don't deploy apps (yet). I barely touch my terminal. So when I say I want to talk about deployment, what I really mean is what the platforms let you actually do with the thing you've built once you click publish.

The trick is that "publish" sounds like a destination, but it isn't. On the free tier, you're getting a tenant slot on the platform's domain - something.replit.app, bolt.host, or lovable.app - with the platform's branding stamped on it. Replit's free tier doesn't let you connect a custom domain, and your app goes to sleep after 5 minutes of inactivity, so it cold-starts every time someone visits. Lovable's free tier forces all your projects to be public, slaps a mandatory Lovable badge on them, and gives you 5 lovable.app subdomains for deployment. Bolt at least lets you export the code to GitHub and push to Netlify or Vercel for free, which was easily the most generous deployment situation I tested.

Basically, if you want your app to look anything like a real product, you're gonna have to get a paid tier. And even then, that doesn't grant you ownership. And for me specifically, who doesn't know much about development, if I want to host it independently of the platform, suddenly I need to know what environment variables are, what a build command is, how to wire up a deployment pipeline. That's not vibe-coding anymore, that's just coding.

Every bug costs you

The platforms basically make money when their AI messes up

"Just pay for it" doesn't really work when there are dozens of vibe-coding tools on the market and each one charges differently - there's credits, tokens, daily caps, monthly caps, effort-based billing, and so on and so forth. I can't subscribe to all of them. And the cap itself isn't really the issue anyway, the issue is what I'm burning credits on. Most of the time, you're not going to pay to build, you can easily whip up a full product in the free tier. What you're paying for is to debug, because every fix the AI makes costs credits, and every fix introduces a new bug that costs more credits.

A Figma Make user posted a long breakdown in the official Figma forum calling this the "iteration tax" - they'd hit their third lockout in a week after spending hundreds on credit expansions in two weeks, with almost all of those credits going to debugging and fixing logic rather than building new features. The platform makes more money when its AI messes up, and I'm basically subsidising its mistakes.

Then you hit the 70% wall

The first version is always the most impressive, but the final stretch is where most projects die

The iteration tax I just unpacked above wouldn't sting nearly as much if I could actually finish what I started, and this is where the 70% problem comes in. It's a named pattern - Addy Osmani, a Google Chrome DevTools engineer, describes it as the moment non-engineers reach roughly 70% of a working solution quickly, and then the final 30% becomes an exercise in diminishing returns as each fix surfaces new bugs in an accelerating cycle. The first version is always the most impressive, and I've seen this too: I usually get a clean layout, working interactions, and it looks like a real product. Then I start trying to finish it and that's where it gets ugly.

The reason for this comes down to what the demo actually is. The "demo" is the visible part of the app - the layout, buttons that respond, and the happy path clicking through end to end. That visible part only accounts for around 20% of the code in a real production app, while the other 80% is the invisible stuff like error handling, edge cases, security, performance, accessibility, and monitoring. So the AI gave me the demo-able 20% in minutes, but the rest is what I'm now trying to drag out of it one bug at a time, and the AI was never going to write that part on its own.

I built my own design tool using Claude Artifacts and Claude Design, and this is exactly what happened (and I'm on the paid plan). It took a million iterations for me to finally getting something workable, and even then, the end product was still far from a complete design tool.

Iteration introduces regression

Fix one problem, introduce another

This is the same problem as the 70% wall from a different angle - the tools are bad at holding onto what already works while changing something else. I felt this in my own Replit test for a music and mood tracker tool I tried to build. The first version had a great layout but ugly colors. The second version fixed the colors and broke the layout. I literally couldn't have both at the same time. And, again, it's the same thing that happened when I built my design tool with Claude - fix the layers, lose the opacity. Fix the opacity, lose the ability to grab the control points. And so on.

A Red Hat Developer piece quoted a Reddit developer who summed this up pretty well: "AI is still just soooooo stupid and it will fix one thing but destroy 10 other things in your code." Part of the cause is that the AI doesn't really remember what it did yesterday - every session it makes fresh decisions, sometimes contradicting earlier ones. Whack-a-mole is the word everyone reaches for, and it fits.

Built to demo, not to ship

None of this is to say vibe-coding tools aren't useful. They genuinely are - I wouldn't have built half the things I've built without them, and watching a prompt turn into a working interface still doesn't get old. But these issues here show up in roughly the same spot across every tool, and they're worth knowing about before you sink time and money into one.