> 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.
I agree with you. There is an advantage to being first on market, but the "damn the consequences" part is very much VC-fueled. Start-ups going to market (and failing) as fast as possible is very much in the financial interest of the VC, but generally good neither the startup nor its employees nor the ecosystem.
I've lived through several semi-disastrous VC-pushed early product launches, and have seen some being sufficiently bad to entirely destroy a product, despite it being extremely useful.
There is a balance between getting to market as fast as possible and avoiding an architecture that will immediately make it hard to iterate after MVP.
The problem is that a lot of engineers don’t know how to not over engineer and waste time. And product/sales usually don’t know how to strike the balance.
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.
This is true, except that in my experience, senior management seems to have a real hard time, differentiating between “ship-quality, but sparse, MVP,” and “lash-up, crap-quality prototype.”
> 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.
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.