Comment by ChicagoDave
1 month ago
This goes way deeper than open source businesses.
Imagine I’m a company just big enough to entertain adopting Salesforce for CRM. It’s a big chunk of money, but our sales can absorb the pain.
With GenAI as an enterprise architect, one of the options I’m now recommending is to create a custom CRM for our business and skip the bloated enterprise SaaS platform.
We can gather CRM requirements fast, build fast, and deliver integrations to our other systems incredibly fast using tools like Claude Code. Our sales people can make feature requests and we can dogfood them in a few days, maybe hours.
GenAI development tools are rapidly changing how I think about enterprise software development.
If your core business is software-based offerings, your moat has been wiped out.
A handful of senior engineers can replicate any SaaS, save licensing costs, and build custom applications that were too risky in the past.
The companies that recognize what is happening and adapt will win.
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.
1 reply →
>> Our sales people can make feature requests
I can tell you with near-100% certainty. This isn’t what you want to happen. Disaster in the making.
Just because you can doesn’t mean you should. There is very little competitive advantage to be gained from this type of effort in most companies.
What we "want" and what businesses will demand are very different things. I can tell you from 40 years build software, all companies care about is functional software. They don't care about code quality, maintainability, or tech debt. Never seen a single CTO say, "Let's carve out 20% of our sprints for tech debt," even though as architects we recommend something like that all the time.
The motto has always been, "Make it work."
Not, "Make it perfect."
I think we are both saying similar things here (believe it or not). Sales leaders turnover with surprising frequency - 18-24 months. About the time the sales team tells you what they “want” and you fine tune it, they will be gone. The next person will come in and probably scrap 50-75% of what the prior leader did. New requirements.
Meanwhile, besides functionality, you’ll want/need to plug in the latest and greatest go to market tools for marketing -and demand gen. But… that’ll be a custom effort, too.
Along the way you’ll also realize that you’re missing out on the most common practices in the industry because you built some idiosyncratic tool that only is relevant to your company.
History may very well prove me wrong, but I think you’re underestimating the expertise that underlies these products and platforms. It’s not just code, and the costs of getting it wrong are more than just an engineer’s time. When you waste time in GTM the impacts on the business and valuation are not linear, they’re exponential.
Agreed. We went from “internalise your core business and contract what doesn't give you an edge” to “actually just build everything in-house with AI”. Maybe that’ll be the better option in the end, but for now it looks like tons of wasted effort. 100x developers working on the wrong thing.
Yep agreed, totally changes build vs buy decisions. Which is not to say it's always "build" now, but the calculation has changed.