zlacker

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.

>>torgin+(OP)
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.

>>mattma+c4
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.