SaaS software, by it's very nature, tends to gets tested tons more than your inhouse software. It also has more devs working on the software. It is almost certainly more stable and can handle more edge cases than anything developed inhouse. It's always a question of scale.

But what you're describing is the narrow but deep vs wide but shallow problem. Most SaaS software is narrow but deep. Their solution is always going to be better than yours. But some SaaS software is wide but shallow, it's meant to fit a wide range of business processes. Its USP is that it does 95% of what you want.

It sounds like you were using a "wide-shallow" SaaS in a "narrow-deep" way, only using a specific part of the functionality. And that's where you hit the problems you saw.

I am speaking from experience. We have a SaaS tool for example to to CI/CD. It's super expensive, has a number of questionable design choices.

It's full of features, half of which either do not work, or do not work as expected, or need some arcane domain knowledge to get them working. These features provide 'user-friendly' abstractions over raw stuff, like authing with various repos, downloading and publishing packages of different formats.

Underlying these tools are probably the same shell scripts and logic that we as devs are already familiar with. So often the exercise when forced to use these things is to get the underlying code to do what we want through this opaque intermediate layer.

Some people have resorted to fragile hacks, while others completely bypassed these proprietary mechanisms, and our build scripts are 'Run build.sh', with the logic being a shell or python script, which does all the requisite stuff.

And just like I mentioned in my prev post, SaaS software in this case might get tested more in general, but due to the sheer complexity it needs to support on the client side, testing every configuration at every client is not feasible.

At least the bugs we make, we can fix.

And while I'm sure some of this narrow-deep kinds of SaaS works well (I've had the pleasure to use Datadog, Tailscale, and some big cloud provider stuff tends to be great as well), that's not all there is that's out there and doesn't cover everything we need.

That's my point, "It's full of features". You said it yourself.

You have bought a shallow but wide SaaS product, one with tons of features that don't get much development or testing individually.

You're then trying to use it like a deep but narrow product and complaining that your complex use case doesn't fit their OK-ish feature.

MS do this in a lot of their products, which is why Slack is much better than Teams, but lots of companies feel Teams is "good enough" and then won't buy Slack.

I'm arguing this is an entirely flawed product category (which might have elements of fraud as well) - things that are easy to get started with, but as your skill level or the requirements complexity increases, you start to see the limitations, and get entangled in the 'ecosystem', so given a sufficiently knowledgeable workforce, you are at a net negative by year 2 or 3 compared to experts having built something bespoke, or going the open-source route.

I'm sure you have encountered the pattern where you write A that calls B that uses C as the underlying platform. You need something in A, and know C can do it, but you have to figure out how you can achieve it through B. For a highly skilled individual(or one armed with AI) , B might have a very different value proposition than one who has to learn stuff from scratch.

Js packages are perfect illustration of these issues - there are tons of browser APIs that are wrapped by easy-to-use 'wrapper' packages, that have unforeseen consequences down the road.

This is true when SaaS is a simple widget for everyone. The problem is that when SaaS becomes a hydra designed to do a million things for a million people, the extra eyeballs aren't helping you, they're creating more error surface.

On top of that, SaaS takes your power away. A bug could be quite small, but if a vendor doesn't bother to fix it, it can still ruin your life for a long time. I've seen small bugs get sandbagged by vendors for months. If you have the source code you can fix problems like these in a day or two, rather than waiting for some nebulous backlog to work down.

My experience with SaaS is that products start out fine, when the people building them are hungry and responsive and the products are slim and well priced. Then they get bloated trying to grow market share, they lose focus and the builders become unresponsive, while increasing prices.

At this point you wish you had just used open source, but now it's even harder to switch because you have to jump through a byzantine data exfiltration process.