| ▲ | keeda 9 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... | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| ▲ | Sleaker 8 hours ago | parent | next [-] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||
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. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| ▲ | skissane 7 hours ago | parent | prev [-] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||
> 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. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||