Hacker News Reader

>> 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'm skeptical "get to market as fast as possible, damn the consequences" is as relevant today as it was 10 years ago.

People have to be careful not to miss their window trying to be perfect, but first and broken isn't a clear winner over second and working anymore.

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.

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.

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.

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.