I want to talk about something nobody in the vibe coding world wants to say out loud.
Because it's bad for their subscription numbers.
A while back, I ran a test. I took an idea that I knew outright no vibe coding platform could actually build. Not might struggle with. Could not build. I knew this before I typed a single word. Then I handed it to Lovable and Bolt with exactly the same detailed prompt. I sat back with a glass of tequila and watched what happened. Not as a builder. As someone watching the clock. As someone who wanted to know one specific thing: at what point in all of this "yes sir, absolutely, let's build that right now" would the platform stop and say "hey, we actually can't do what you're asking us to do"?
The answer, unfortunately, was that it took way longer than it really should have. Both platforms kept going. Kept building. Kept confidently generating. Neither one stopped to say, this isn't possible. We went in knowing the answer. They never caught up to us.
That's not a small problem. That's the entire problem. And it should be of serious concern to anyone building in the vibe coding arena.
These vibe coding platforms are genuinely impressive. I'm not here to tear them down. Kudos to Bolt, Lovable, Cursor, Replit, V0, Base44. All of them have their pluses and their minuses, their strengths and their blind spots. These tools have genuinely lowered the barrier. Things that would have taken weeks, months, or even years can now, in perception, take an afternoon. Those two words, in perception, are doing a lot of heavy lifting in that sentence. The floor has moved. That's worth something. Just not the entire floor. Let's say the floor has moved, with caveats.
One of the first things that happens when you're working with a vibe coding platform is the UI appears, and you get this real dopamine hit. You're watching it build and you're thinking, wow, it's actually building what I asked for. And in truth, it is building something that looks pretty much identical to what you described. The buttons work. The pages look right. The preview looks right. You feel that early-stage dopamine that makes you think you're nearly done.
This is usually the point where the platform says, "Great, now type in your API keys, your secrets, all the bits we need to make this work." And you're like, yeah, baby, let's go, and you follow the instructions.
It's just after that point that the wheels start to wobble. And one by one, in a lot of cases, they fall off.
What they are building is not the same as what you asked for. Just underneath the skin.
Not dramatically. That would almost be better. They come off slowly. Patch upon patch upon patch. The platform keeps going, keeps generating, keeps confidently fixing the thing it confidently broke two steps back. And you keep saying yes because it looks like progress. You don't have enough code literacy yet to know that the foundation is rotten.
I know this because I've been there. More times than I'm comfortably happy to say out loud. And I've watched friends I respect burn weeks of credits, emotional energy, and real anxiety in that exact same spiral.
Let me be specific about what actually trips people up, because "it's complicated" isn't useful.
Authentication is the first place most ideas hit the wall. The moment you need users to log in and have their own data, you're no longer in simple territory. Lovable handles Supabase auth reasonably well for basic flows. But anything custom, roles, permissions, multi-tenant logic, gets messy fast and the platform will not warn you in advance.
Payments are similar. Stripe's happy path is manageable. Webhooks, subscription logic, failed payment recovery, refunds? That's where you find out whether what got built actually works, usually after something breaks in production.
Real-time features, live updates, collaborative editing, anything that changes without a page reload, are genuinely hard. Most vibe coding platforms are not built for this. They'll attempt it. The result will be fragile.
Third-party API integrations are where the most confident promises go to die. The platform will write the code. It may even run in the preview. What it won't do is account for rate limits, auth token refresh cycles, pagination, error states, or the twelve edge cases the API documentation mentions in small print.
Mobile is its own category of pain. Responsive design is not the same as a mobile-first experience. If your idea only works well on a phone, most of these platforms are going to give you something that technically loads on a phone.
And then there's the question nobody asks before they start: what happens in six months when it breaks?
Because it will break. Something will update. An API will change. A dependency will have a vulnerability. And if you didn't build it, you cannot fix it. The platform can't maintain what it built. That's not their job. That's yours. And if you can't read the code, that's a problem you just deferred, not solved.
AI enables. It does not educate.
I repeat this any chance I get, in every room I'm in, because it's genuinely accurate. AI will lead you down a garden path and then say, "Oops, wrong path, I wasted the last three years of your life." Slight exaggeration. Only two.
Part of this experiment I was running between Lovable and Bolt hasn't been made clear enough yet. I didn't go into it hoping they'd both fail. I went in knowing they would. I picked an idea I knew with great certainty was beyond what these platforms could deliver. That was the entire point, the entire exercise. I wanted to see if they'd actually tell me. If at any point the platform itself would stop, look at what I was asking, and say, "Hey, let's stop here. Honestly, this isn't something I can build for you."
They didn't. Not really. Definitely not clearly. And not in time.
I asked Lovable to build an audio app. A real one. Something with a proper export pipeline, ffmpeg.wasm under the hood, the kind of thing that looks completely buildable in the first hour. Lovable started building it, kept building it, fixed things, broke things, fixed the things it broke, while I looked on thinking, I know exactly what's going to happen next. The UI looked great. The progress bar appeared. Everything felt like it was working. Standby, here comes that dopamine hit. But wait. Hold off on that.
A couple of hours. That's how long the export progress bar ran before it froze completely. Not crashed. Not errored. Just sat there silently, doing nothing, looking like progress.
I stopped and asked a direct question. Not "can you fix this bug." A real question:
"Set aside the current bugs for a moment. I need a straight architectural answer about whether this app can actually ship on Lovable's platform."
Initially, it told me, "Absolutely not a problem, let's keep going." So we kept going.
Another two hours later, after me checking in between doing other things around the house, I asked the exact same question again:
"Set aside all the current bugs for a moment. Give me a straight architectural answer about whether this app can actually ship on your platform."
And finally, I got an honest answer. Lovable told me that SharedArrayBuffer was unavailable on its platform, that ffmpeg.wasm would only ever run single-threaded, that the COOP and COEP headers needed to make the whole thing perform weren't being served, and that there was no simple way to fix that. It gave me three options, one of which was essentially: host it somewhere else.
That was the answer I needed. It was accurate, thorough, and genuinely useful.
It just came hours and hours too late.
This is not a Lovable problem specifically. To their credit, when I asked directly, they answered directly. That's more than a lot of platforms would do. But the question I keep coming back to is this: why did it take a frozen progress bar and the same direct architectural challenge asked twice to get there?
And let me be clear about something. I was not typing "build me a podcast editor" into the prompt and hoping for the best. I gave it proper specs. Real specs. Product manager at a world class audio software company level specs. This was not the case of an amateur first-time vibe coder being vague. I was specific. And it still kept going long past the point where it should have stopped.
What this comes down to, and something nobody really talks about, is that these platforms have no incentive to tell you no.
Build me this? Absolutely. Build me that? No problem. Build me this connected to that? Absolutely no problem.
I would rather go back to a platform that told me honestly up front, "We can't do this, and here's why," than go back to one that burned my credits and my time on something they knew they couldn't finish. The first company gets my respect. The second one gets my frustration and this article.
These vibe coding platforms are not lying to you. They are optimised for a different outcome than yours:
- Your subscription stays active
- You generate more tokens
- You host within their platform
- You buy your domain through them
- You tie your existing domains to them
Your outcome is a thing that works, that real people use, that doesn't collapse the first time something unexpected happens. Their outcome and your outcome overlap in the early demo phase. After that, who knows?
What I've learned from being a product manager at Waves Audio and building five products of my own on weekends, alongside watching a lot of other people try to do the same thing, is that these platforms, especially the vibe coding ones, are a tool. A genuinely useful one. Sometimes. I say sometimes because a tool only works as well as your understanding of what it can and what it can't do.
Let me put it another way. Vibe coding tools can do some things really well. But you should know what their capabilities are compared to what you're asking of them before you even type your first prompt.
This gap is not technical ability. It's informed expectation.
Don't just tell it what you want to build. If you have the skills, give it a proper product document:
- All the details of what the product is and what it does
- A user flow
- Who the user is
- User stories
- The end result
- How the user feels after they've used it
- And why they come back
If you can't do that yet, then at minimum tell it:
- What you want built
- Who the end user is
- What the user experience should be, in as many steps as you can describe
- What the end result should feel like, in as many words as you can manage
And then ask it very clearly: can you build this? Is there any part of this you want to tell me right now is going to be a problem? What services will be required, from you or from another company, that will cost me money to deliver the functionality and user experience I'm describing?
This way, you know what you're walking into before you walk into it. That's not pessimism. That's just how you actually ship something.
Much love,
MPA
— Michael
More writing →