This is the exception to the rule

in the 90-ies anyone could easily prototype with tools like Access. That still didn't preclude companies from buying their major software from software vendors instead of doing it themselves.

In some sense having customer able to prototype what they want is a good thing. I did it myself as i was at the time on that side, and having a quick-whip-it tool was a good thing to quickly get some feature that was missing in the major software before that major software would add it (if at all). (And if one remembers for example Crystal Reports - while for "reports", it and the likes were in many senses such quick-whip-it tools for a lot of such customization that was doable by the customer.)

So, after initial aftershock - "Ahhhh, we don't need software companies anymore!" - we'll get to the state with software companies still doing their thing just with a lot of AI as "specialization" is one of the main thing in modern economy.

(Of course some companies wouldn't survive the transition just like some companies didn't survive the transitions to client/server, cloud, etc.)

Yep. Wait until they realize one of their vibe coded apps validates everything client side and their entire DB is open to the world.

Yep. It's a funny thing.

You build a Twitter. Profiles have posts, posts can have images, etc. It's very easy to model the database.

But then how do you make money with it? Now you need to build a separate system for advertising? Or do you want to sell subscriptions? Which means you need to build a separate system to handle payments. This is usually the big one, because when you handle money, what happens if there is a bug and you charge someone without delivering anything? How do you prevent fraud? How do you handle disputes?

Someone posted something illegal. What do you do in this situation? Do you call the police? The FBI? What kind of data do you give the authorities? How much data SHOULD you have been logging in the first place in case something like this happens?

One user doesn't like you so he bought a botnet to DDoS your website. How do you handle this? Are they mass posting? Mass creating accounts? Is it possible for them to exhaust all the usernames possible and then nobody can create an account anymore?

Your website is online but if the server blows up you'll lose all the data in the database. You need backups. You need a system to ensure the backups are actually working. But then some guy from the UK said he wants his posts all deleted. What are you going to do now, because his posts are also in the backups, and you don't want to touch those.

Trolls are posting things against the ToS. Who handles these things? Shadowban? So there needs to be a shadowban system? Moderators? So there needs to be a moderator-only section of the website? Should this be integrated with the main website or not?

Then you look at this horrendous mess of 6 paragraphs and you think back about the first paragraph that already did everything you wanted from Twitter. All these other systems, most of the work, and all you actually wanted was the first paragraph.

That's not like "Who need Photoshop everyone can just vibe code their own photoshop"

They could just download GIMP or find cheaper alternative, that was always an option

I vibe coded Stripe and Okta in a weekend. Time to deploy to prod and save some money!

I agree!

Although the proponents of this idea argue that companies will create and (!) maintain many tools in-house.

It’s not so much about running a business, since you don’t sell anything and only have internal customers.

SaaS is mostly sales.

The B2B startup motto of "where someone is using Excel to do something other than accounting, there's a startup waiting to happen" has been shockingly resilient over the decades, and I suspect will continue to be.

So… next week then?

As my manager said to a young me when I offered to replace our CMS, and promised I could do a good job at it, "you could probably assemble our office furniture too, but I don't want to pay you to do that either"

We have replaced many SaaS with inhouse solutions, but most of these where lacking in quality and where part of our existing core business model which we where not "owning" prior. We can flip the argument where we have lost customers and revenue due to SaaS not delivering

The gains is generally more seen outside of monetary as these SaaS solutions where holding us back for achieving our goals and improving our services to our customers. As in the end of the day our customers do not care if "insert SaaS" is having issues, it will always be our problem to own.

This is because what management wants and what builders want are not aligned, not because the quality of JIRA is so amazing that no other alternative could ever be created. JIRA is fine but many people I know that use have some qualms with it because the bloat is pretty crazy.

And don't forget the safety in getting to say "our systems are down because of [X TRUSTED SOFTWARE FROM LARGE KNOWN BRAND] and we're just waiting for them to fix it" instead of "our shitty internal tooling is broken and no one knows how to fix it"

This feels like it goes along the lines of "people's vibe code is cluttering up our PR's, people still need to review" -- it misses the boat: models are already capable of getting you up to speed on how the code is organized and works, in as much as you want to or need to be up to speed. They are already helping me cut down review time because I don't need to aimlessly hop around, I have a good starting point that I can scrutinize and dialogue about. Same thing here: employee leaves company -- about 3 years ago you would be right, now the company is left with an unmaintainable mess of legacy code and tech debt. TODAY this just doesn't matter. No one really needs to read that code too closely, it's already easy for agents to digest and explain and modify.

Doing this today, in production, with full trust, is clearly not wise, but the writing is clearly on the wall that this is going to be the norm more and more over the coming years. The times they are a-changin.

I think you can avoid the pain by thoughtfully designing it to avoid lock-in. You want it so that if needed, a dev can vibe-code a migration tool to the equivalent SaaS offering. AI lowers the barrier for creating these in-house replacements, but it also lowers the barrier for scrapping them too.

Even more accurate (I work in this space):

3. Bugs creep in, feature request pile up.

4. Employee continue in the company and request help (or the managers see the need):

4.1 They hire more, but if all are vibe-coders too

4.1.1 The product gets more complicated (no more complex, that good developers can manage!)

4.1.2 Bugs creep in, feature request pile up.

4.1.3 People start to get desperate, not worries! now:

4.1.3.1 Somebody vibe-code a new alternative that solves the immediate problem

4.1.3.2 Bugs creep in, feature request pile up.

4.1.3.3 Needs to sync with the other tools

4.1.3.3.1 Somebody vibe-code the sync that solves the immediate problem

(the saga continue)

In parallel:

4.2 Eventually is obvious that need external help

THEN:

4.2.1 They ask for consultors for build tool, of course, from a company that has embraced the IA!

4.2.2 They build new shinny tool!

4.2.3 Bugs creep in, feature request pile up.

4.2.4 Needs to sync with the other tools ....

AND:

4.3.1 They ask for consultors, to teach them what to do, of course, from a company that has embraced the IA!

4.3.2 New shinny theory of how do the thing with IA is now being implemented!

4.3.3 It require a rewrite of not only past solutions but, a change of how the company behave!

4.3.3.1 Needs to sync with the other tools .......

4.3.4 And it spark beautiful office/political debates around some philosophical whatever that also trigger changes in the structure, hiring or whatever, alienating the people that has been working there, that after months, has started getting the handle of it!

4.3.5 Employees either leaves the company or moves on to another project.

4.3.6 New employees arrive, with a wild new IA tool and different vibes that vibe-coding!

... the saga continues

5. Is now clear that it need to buy a product form a well stablished software provider

5.1 And all of them are now in the IA craze!

.............

That's a huge part of it. But also you presumably hired a full-time programmer for a reason, and in almost every case that reason was not to have somebody to write and maintain your CRM system. So any system they build and maintain is not just another thing for you to worry about, it's a huge chunk of time that the developer isn't doing what you hired them for.

Depends on the size of the organization.