alt Hacker NewsIn my experience, SaaS is also fragile. It's real software, with real bugs. Most complex solutions offer an extensible API/scripting support with tons of switchable/pluggable modules to integrate with your company's infra. This complexity most often means that your particulary combination of features is almost wholly unique, and chances are your SaaS has much less open mindshare/open source support than any free solution.
We often ended up discarding large chunks of these poorly tested features, instead of trying to get them to work, and wrote our own. This got to a point where only the core platform was used, and replacing that seemed to be totally feasible.
SaaS often doesn't solve issues but replaces them - you substitute general engineering knowledge and open-source knowhow with proprietary one, and end up with experts in configuring commercial software - a skill that has very little value on the market where said software is not used, and chains you to a given vendor.
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.