Andrew C Wang's Blog

Software still has a Moat

Edit History

AI singularity folks have recently died down their hype that AI will slaughter SaaS. The majority of firms still have business moats, loyal communities, and built up wisdom around product thesis and feature development to ensure the hurdle of having an AI agent build custom business software is too high of a bar.

Plenty of firms use consultancies to build internal applications. Shopify completely replaced Datadog for instance. In many large, non-technical firms they will use someone like Deloitte who introduces an Indian dev shop to code applications and integrations with other SaaS vendors that executives have chosen. However, there is still a moat in traditional SaaS outside of the aforementioned moats the common debate points out online.

Code used to be a moat because software engineers were expensive. You could only build so many features with a given number of engineers, so the moat was literally cash which correlated with engineering size. At some point, there were diminishing returns in building features, and scale and complexity required feature development to be replaced with infrastructure work to handle load. Regardless of scale, code was a cash incinerator because of expensive software engineers. Software engineers at the best startups were also usually very intellectual. Finance and consultancy firms used to hoard Ivy League new grads with lucrative cash, but tech offered a more relaxing career path. Because of that, tons of intellectual people moved into software; combined with high profit margins and huge exits, that salary made SaaS startups expensive.

With coding agents, the assumption was code can no longer be the moat. Full stack engineering can be done quickly and cheaply. However, as I’ve said time and again: software models processes. Software has always been intertwined with logic, and we follow steps in various settings like recipes in logical order. This modeling of processes has been sped up. What hasn’t been sped up and possibly never will be is the business behind that process.

An example is integrations. I used to work on B2B SaaS integrations; we had to integrate with every SaaS provider that our clients used in order to activate users and set up certain permissions and groups (essentially authorization). However, tons of vendors had their API hidden. Those SaaS integrations were oftentimes enterprise, so they had the enterprise API endpoints we needed. Yet, they required partnerships. Rippling does the same thing to become partners. We were partially inspired by Rippling to even incentivize integration partnerships through revenue splitting.

Another form of processes being slowed by business is Stripe Atlas. Stripe Atlas allows people to set up Delaware C Corps quickly. After signing up, Stripe Atlas offers perks or essentially discounts on internal business operations such as payroll. Gusto, an HR and payroll software, for instance is offered as a perk. However, if you started a Gusto competitor, as a new startup, you might want to market it on Stripe Atlas. However, you likely need to build up some more reputation and customer base before Stripe will introduce your startup.

These are competitive advantages at a basic level. Code can’t be built if those partnerships didn’t exist. There are other examples where code is not the limiting factor but people and business is. The Stripe Atlas example is not just a partnership issue and a business marketing competition issue, but it is also a trust issue from both Stripe’s side and the end consumer side. Even for the new startup, is it ready to take in Stripe Atlas users who come from all over the world? Can they handle that global user base complexity yet (i.e. what if a user isn’t from the U.S.)? In the case of complexity, in the future, maybe an AI can know all the intricacies to handle that complexity, but does the founder want to handle it and risk whether the AI is wrong and messes up stuff and thus face legal issues and monetary damages? At the end of the day, code modeling processes may not be a moat anymore, but everything behind that code is still a barrier because the bottleneck is still humans.