3 ms·

Some interesting long-term, directional ideas about the future of software dev here but the implied near-termness of SaaS being disintermediated ignores how man

Some interesting long-term, directional ideas about the future of software dev here but the implied near-termness of SaaS being disintermediated ignores how management in large orgs evaluates build vs buy Saas decisions. 'Build' getting 10x cheaper/easier is revolutionary to developers and quite possibly irrelevant or only 'nice-to-have' to senior management. Even if 10x cheaper, internally built Saas tools don't come with service level agreements, a vendor to blame/cancel if it goes wrong or a built-in defense of "But we picked the Gartner top quadrant tool".

sidereal1 9mo ago
> implied near-termness of SaaS being disintermediated Also, is this even true? The author's only evidence was to link to a book about vibe coding. I'd be interested to hear anecdotes of companies who are even attempting this. Edit: wow, and he's a co-author of that book. This guy really just said "source: me"
condiment 9mo ago
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 9mo ago
  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.
alexjray 9mo ago
Yeah I don't buy the build internally argument. Its not necessarily the building of an internal tool that is the problem it's the maintenance and service level guarantees that you get from a vendor that are arguable more valuable so you can focus on the thing that matters for your company. Product market fit is now more important than ever and there are so many additional options now; focus on the "right" thing is more valuable now than ever before.
tobyjsullivan 9mo ago
Isn’t this a form of what he labels the “human coefficient”? Some businesses prefer tools built by other businesses for some tasks. The author advocates pretty plainly to identify and target those opportunities if that’s your strength. I think his point is to recognize that’s moving toward a niche rather than the norm (on the spectrum of all software to be built).

sidereal1 9mo ago

> implied near-termness of SaaS being disintermediated Also, is this even true? The author's only evidence was to link to a book about vibe coding. I'd be interested to hear anecdotes of companies who are even attempting this. Edit: wow, and he's a co-author of that book. This guy really just said "source: me"

condiment 9mo ago

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 9mo ago
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.

alexjray 9mo ago

Yeah I don't buy the build internally argument. Its not necessarily the building of an internal tool that is the problem it's the maintenance and service level guarantees that you get from a vendor that are arguable more valuable so you can focus on the thing that matters for your company. Product market fit is now more important than ever and there are so many additional options now; focus on the "right" thing is more valuable now than ever before.

tobyjsullivan 9mo ago

Isn’t this a form of what he labels the “human coefficient”? Some businesses prefer tools built by other businesses for some tasks. The author advocates pretty plainly to identify and target those opportunities if that’s your strength. I think his point is to recognize that’s moving toward a niche rather than the norm (on the spectrum of all software to be built).