Comment by yowlingcat
2 months ago
It isn't that simple. One of the implicit tradeoffs you make buying SaaS is that the overall cost of evolution (development and ongoing maintenance) is subsidized across all of the investment resources and customer base of the vendor. With CRM in particular, ecosystem integration is one of the heaviest buildouts there is because each point solution integration can very significantly in complexity and is also where the combinatoric explosion of misbehavior sets in.
When you decide to pull that in house, you are implicitly burdening yourself with the cost of the buildout as well as ongoing maintenance. True, you could probably knock together an okay v1 of CRM yourself inhouse. But are you really going to get it to and maintain production level quality over time at a lower total cost of ownership? I'm skeptical.
The theoretical party you are describing would probably be better served by simply avoiding Salesforce in favor of a next gen CRM that is both more cost effective and easier to customize. In enterprise contexts, even HubSpot is effectively next gen, but there are also products like Attio et al that have a ton of adoption and strong integration ecosystems (albeit not at the Salesforce level).
When you buy enterprise software from a vendor you are buying more than "just software" you are also hiring a company's services. And the inverse is correct as well, when you choose to build it in house, you are implicitly choosing to hire a team internally to resource all of the services you would've expected that vendor to provide.
Certainly, this tradeoff can still make a lot of sense for some companies. The acid test for that, in my opinion, is whether said company could (and would) actually successfully sell the product they build internally on the open market. If the answer to that is "yes", the prospect of turning a cost center into a profit center can potentially bear significant long term ROI to the company.
100%. As an EA you always examine and explain the trade-offs to the business. In many cases that trade-off will remain and buy vs build leans towards buying.
My point is the decision point has moved. Where five years ago there’d be zero discussion of building internally, those discussions are going to be very different.
I believe many tech oriented companies will pull SaaS capabilities inside and as GenAI developer tools improve, the line will keep moving.
And we don’t need SaaS professional services anymore. Claude Code replaces that entire business model.
A view I have which feels controversial these days is that GenAI code tools are a net asset to code being held by entities that "should" hold them (ie workloads where code is a profit center not a cost center) and a net liability to the opposite. SaaS is a very squishy word and includes a lot things which are more accurate to call tech enabled services; Salesforce being one of the best examples (but you could say the same about many ERPs).
Maybe my biggest disagreement with your view is I think it is simultaneously far too conservative and far too aggressive at the same time. Where there was previously a decision about buy vs build, I disagree with the belief that many tech oriented companies will pull SaaS capabilities inside as GenAI developer tools improve because the cost of "build" is actually not going to get comparatively cheaper compared to the risk of "buying" - if anything, the risk of "building" internally with GenAI tooling that you were considering "buying" is significantly higher unless you are prepared to truly own it, that is go head to head with the entire rest of the market focuses on building and selling that tool as their full-time corporate focus. The actual risk of owning a tool internally making allowances for GenAI tooling is a lot higher than folks realize because GenAI tooling has a lot more risk of creating vibeslop and the only way to avoid that is to be dedicated to producing that tool as one's full time job and serving the needs of the entire market that needs it in that process. This is impossible to do with an internal tool.
The flip side of that same realization is why I also believe that your view is too conservative. The company that might be more empowered to consider building Salesforce internally with better tooling is not competing with Salesforce -- they are competing with the market that is going to /takedown/ Salesforce and a future version of themselves that would've used the future successor to Salesforce. Such a company is probably not in the business of building and selling CRMs although they are likely in the business of using such a CRM. The risk of making that conflation would be to stretch existing resources thin and turn the high interest credit card of tech debt and turn it into a payday loan with GenAI vibeslop.
I do not view GenAI as a democratizer. I view it as an accelerator with the capabilities to accelerate not just "winners take all" dynamics for the top companies that invest enough to avoid vibeslop, but "losers lose all" dynamics in the supply chain for everyone else who tries to wing it to capitalize before inevitably losing against future incumbents, or try in vain to turn a legacy firm into an innovator before inevitably losing against tech debt.
Everyone likes to believe they'll be able to use these great tools to become a future incumbent. But becoming a future incumbent is something that is very hard to do unless your org + book of business + funding + tools is better than someone else's org + book of business + funding + tools. That is why I don't think it actually changes the buy vs build decision that much; the decision should probably still be to buy, it's just changing the question of what exactly should be bought.
Excellent response. I think my position is that I don’t vibe code and most senior/deeply experienced dev/arch’s are doing something else.
We’re not coding. We’re orchestrating well constructed applications that follow proven principles (DDD, behavior focused, packaged business capabilities, behavior unit testing).
We’re extracting high value from GenAI.