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.

And it's never just the slapping together. it's the ktlo: a perpetual tax on your eng team for every thing they own.

No matter what it's a tax on your engineering team to keep it together. But the most brittle parts are always right at the seams. It's not as hard to sew together components when you can cut the cloth down to fit together. Who knows how it'll shake out.

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.

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"

The law of comparative advantage strikes again.

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.

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

depends how much the vendor chargers.

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.

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.

As Spolsky said a quarter century ago, "bloat" is just "bugs somebody already fixed". (He may have actually said that about "cruft", but the idea still applies.)

Hard to believe that it was that long ago!

Yeah, I moved my team to Jira and sold it as "yes Jira is terrible but all the others are much worse".

I also spent a solid two weeks in the admin panel chainsawing as much Jira bloat as I could. It's perfectly adequate now.

The market seems convinced it will happen, considering its stock price is in the gutter

I'll be glad to admit I'm in the wrong when it actually happens.

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

You're ignoring the biggest part of SaaS as far as management is concerned.

There's a large, stable entity that management can sue if something goes very wrong.