[condiment]

I've made many business cases for internally-built SaaS tools, and they always rest on the idea that our probability of success is higher if we staff a team and build the _exact thing_ we need versus purchasing from a vendor and attempting an integration into our business.

It's far more challenging to win the 'build' argument on a cost savings approach, because even the least-savvy CIO/CTO understands that the the price of the vendor software is a proof point grounded in the difficulty for other firms to build these capabilities themselves. If there's merit to these claims, the first evidence we'll see is certain domains of enterprise software (like everything Atlassian does) getting more and more crowded, and less and less expensive, as the difficulty of competing with a tier-1 software provider drops and small shops spring up to challenge the incumbents.

[mrandish]

Agreed. I was going to add (but didn't) that the first evidence of an 'AI unlock' on SaaS wouldn't be internal builds but many new, much cheaper competitors appearing for leading SaaS tools. Your point about the best arguments to internally build SaaS being 1) integration savings, and 2) better fit, is spot on. But senior management has to balance those potential benefits (and the risk an internal effort fully delivers on-time & budget) against sticking with 'the devil we know' which works (imperfectly) today.

In my experience, a bigger blocker to C-level approving internal SaaS development is it diverts capital and scarce attentional bandwidth to 'buying an upside' that's capped. Capped how? Because, by definition, any 'SaaS-able' function is not THE business - it's overhead. The fundamental limit on a SaaS tool's value to shareholders is to be a net savings on some cost of doing business (eg HR, legal, finance, sales, operations, support, etc). No matter how cheap going in-house makes a SaaS-able activity, the best case is improving margins on revenue. It doesn't create new revenue. You can't "save your way" to growth.