> Startups save weeks getting to MVP with Vibe Coding, then spend comparable time and budget on cleanup. But that’s still faster than traditional development.

That's the core of situation as described in the article. I wonder how true that is, that it's faster overall than having developers build the MVP.

From what I've seen, I think developers can build just as fast, especially with AI assistance. They may not want to though, knowing full well the MVP/prototype will go directly into production.

Better to take some time to have a decent architecture early on. Product and management probably see that as a waste of time.

On the other hand, vibe coding allows the product team to make exactly what they want without having to explain it to developers. That's the real draw to this, basically a much better figma.

Perhaps there is a market for a product oriented vibe coding tool, that doesn't pretend to make code, but gives developers much better specifications while allowing the product and business side better input in the process.

>> Startups save weeks getting to MVP with Vibe Coding, then spend comparable time and budget on cleanup. But that’s still faster than traditional development.

> That's the core of situation as described in the article. I wonder how true that is, that it's faster overall than having developers build the MVP.

In a startup it's often very important to show traction, and thus decreasing time to market can be hugely beneficial, even if it costs you more time overall.

The same reason people can rationally take on technical debt in general.

An MVP? Definitely not. A prototype maybe, but...

For building a prototype, unless you have the discipline to not put the prototype into production and your organization has similar discipline, I wouldn't recommend vibe coding. We all know how hard it can be to convince management that he amazing thing they're using right this moment needs to be scrapped and rewritten because the insides are garbage.

No-code tools are better suited and safer to use in that respect.

> knowing full well the MVP/prototype will go directly into production.

If they didn’t think that was happening already, they were fooling themselves.

I remember a quote on here, where they said something along the lines of “If your MVP code doesn’t make you physically sick, you’re spending too much time on code quality.” MVPs seem to inevitably become the backbone of the company’s future.

I guess the service could be more accurately described as “C-Suite Cleanup As A Service,” but no one would hire them, then.

Twitter started as a in Ruby on Rails webapp and everytime Justin Bieber tweeted the whole Twitter would go down and the fail-whale would appear.

But they grew, and one day could afford hiring professionals to rewrite it from scratch on a more scalable and robust stack.