You're not considering opportunity costs and buyers vs. users.

If your senior developers can slap together something better than an expensive SAAS offering you want them directing that energy at your core products/services rather than supporting tools.

And the people deciding to buy the expensive SAAS tools are often not the people using them, and typically don't care too much about how crappy the tool may or may not be for doing the job it's advertising as doing.

Clubbing all saas products together just means you can’t really have a productive discussion. Saas products are on a spectrum of quality, from amazing (stripe, datadog) to terrible (fivetran, github). Its upto you as a user to make a call as to which will serve you best, what you should focus your limited resources on etc.

> what if this time it's senior developers and they actually can slap something together better then the expensive SAAS offerings

A typical SaaS customer will use many pieces of software (we mostly call them SaaS now) across its various functions: HR, accounting, CRM, etc. Each one of those will have access to the same pool of senior devs and AI tools, but they will pour more resources into each area and theoretically deliver better software.

The bigger issue here is the economics of the C-suite have not changed here. Assume a 100 CPG company uses 10-20 SaaS apps. Salesforce might be $100k/year or whatever. 1Password is $10k. Asana $10k. etc. They add up, but on the other hand it is not productive to task a $150k employee with rebuilding a $10k tool. And even with AI, it would take a lot of effort to make something that will satisfy a team accustomed to any modern SaaS tool like Salesforce or Atlassian. (Engineers will not even move off Github, and it's literally built on free software.)

That's before I get to sensitive areas. Do you want to use a vibe-coded accounting system? Inventory system? Payroll? You can lose money, employees, and customer perception very rapidly due to some bugs. Who wants to be responsible for all their employee passwords are compromised because they wanted to save $800/mo?

Then, the gains from cutting SaaS are capped. You can only cut your SaaS spend to zero. On the other hand, if you have those engineers you can point them at niche problems in your business niche (which you know better than anyone) and create conditions for your business to grow faster. The returns from this are uncapped.

TL;DR; it's generally not a great idea to build in-house unless your requirements are essentially bespoke.

To the first question, if your senior devs can do that there's almost certainly something more directly valuable to your business they could be doing than solving a problem your vendor has already solved

The second question is a valid one, and I think it will somewhat raise the bar of what successful SAAS vendors will have to offer in coming years

It that works, nobody would be using Jira anymore, because people would just use a competitor that's cheaper or vibe code their internal Jira tool.

Somehow that has not happened yet in 2026.

There are of course exceptions to every rule, and I'm sure some companies have been successful in building their own in-house tooling.

At the end of the day these decisions are all series of trade-offs, and the trick is understanding your requirements and capabilities well enough to make the right trade-offs.

Nice what ifs, but not valid so far. I get the motivation to think/hope so, but thats not the proper business world right now where big money are. Maybe next year it could start becoming true but then market will be a bit different too