Comment by keeda
15 hours ago
Hmm, I wonder if it would be cheaper to hire a couple of software engineers to vibe-code custom SaaS apps on top of the company's existing data layer instead of paying for a hundred different SaaS subscriptions.
Financial considerations aside, one advantage of having in-house engineers is that you can get custom features built on-demand without having to be blocked on the roadmap of a SaaS company juggling feature requests from multiple customers...
I'm at a large company that is building connections between all of its different financial systems. The primary problem being faced is NOT speed to code things, the primary problem at large companies is getting business aligned with tech (communication) and getting alignment across all the different orgs on data ownership, access, and security. AI currently doesn't solve any of this. Throw in needing to deal with regulation/SOX compliance and all the progress you think AI might make, just doesn't align with the problem domains.
Agreed. The SWEs already receive a steady supply of conflicting demands from every possible business unit; the value add for these teams is a working PMO to prioritize the requests coming in.
Totally makes sense. Turns out that a lot of what Palantir's "Forward Deployed Engineers" do is navigating these bureaucratic and political obstacles to get access to the data: https://nabeelqu.co/reflections-on-palantir -- which may be Palantir's real secret sauce, rather than the tech itself.
> getting business aligned with tech (communication) and getting alignment across all the different orgs
This is what a CEO is supposed to do. I wonder if CEOs are the ones OK with their data being used and sent to large corps like MS, Oracle, etc.
I haven't seen what you're suggesting from a CEO at a large company that's primary business is non-software related. At some point in a businesses life theres an accumulation of so many disparate needs and systems that there can be many many layers of cross org needs for fulfilling business processes. This stuff is messy.
I think I saw it asserted that its easier for a new company, which definitely makes sense as you don't carry along all the baggage.
I work in large projects like this, the CEO doesn't get involved in the little "computer project" except during the project kickoff. Even then, it's just to "say a few words about the people I admire on this team". In large global companies these projects are delegated 3 or 4 levels below the CEO at the highest.
Makes me wonder if they are getting ripe for disruption. Not by a new business model, but a new operating model where a CEO will be tech/ai-aware and push through all these kinds of things.
1 reply →
This is also generally true for all mid to large businesses I've ever worked at.
The code they write is highly domain-specific, implementation speed is not the bottleneck, and their payroll for developers is nothing compared to the rest of the business.
AI would just increase risk for no reward.
> one advantage of having in-house engineers is that you can get custom features built on-demand without having to be blocked on the roadmap of a SaaS company juggling feature requests from multiple customers...
Many larger enterprises do both – buy multiple SaaS products, and then have an engineering team to integrate all those SaaS products together by calling their APIs, and build custom apps on the side for more bespoke requirements.
To give a real world example: the Australian government has all these complex APIs and file formats defined to integrate with enterprises for various purposes (educational institutions submitting statistics, medical records and billing, taxation, anti-money laundering for banks, etc). You can't just vibe code a client for them – the amount of testing and validation you have to do with your implementation is huge–and if you get it wrong, you are sending the government wrong data, which is a massive legal risk. And then, for some of them, the government won't let you even talk to the API unless you get your product certified through a compliance process which costs $$$. Or, you could just buy some off-the-shelf product which has already implemented all of that, and focus your internal engineering efforts on other stuff. And consider this is just one country, and dozens of other countries worldwide do the same thing in slightly different ways. But big SaaS vendors are used to doing all that, they'll have modules for dealing with umpteen different countries' specific regulations and associated government APIs/file formats, and they'll keep them updated since they are forever changing due to new regulations and government policies. And big vendors will often skip some of the smaller countries, but then you'll get local vendors who cover them instead.