zlacker

>>namany+(OP)
It's a tale as old as time that developers, particularly junior developers, are convinced they could "slap together something in one weekend" that would replace expensive SAAS software and "just do the parts of it we actually use". Unfortunately, the same arguments against those devs regular-coding a bespoke replacement apply to them vibe-coding a bespoke replacement: management simply doesn't want to be responsible for it. I didn't understand it before I was in management either, but now that I'm in management I 100% get it.

>>bandra+s01
We are certainly closer now to being able to prototype and go to market faster with a product. In one weekend is a little much but I think its hard to deny that building will continue to expedite. What most developers don't think about is that the marketing, sales, customer service are all non-trivial parts of the business/product and all require legwork that is more than just sitting at an IDE. The nail in the coffin is that the data is a large part of company moats, and new products need time in the market to get that. Migration is also a long process and risky...so to get customers, a newcomer needs to provide way more value than what the incumbent gives.

I imagine you're going to have people trying to automate the whole GTM lifecycle, but eventually the developer that thinks they can bootstrap a one man enterprise without actually doing any kind of social interaction will run into a wall.

>>mym199+j81
In any usable product making a product is like 20% or less. Enter compliance, security, payments and a million other things.

Even if you can build it in a day B2B SaaS will continue to prosper because they sell peace of mind, reliability and compliance. Not features.

Also due to economy of scale it will always be cheaper to buy something from a vendor that sells it to many clients than to DIY it.