Connect your Claude, Codex or OpenClaw for full transcripts on millions of podcasts. Two week free trial, cancel anytime.
Start free trial →No Priors · AI Research & Frontier Labs · October 2026
Elad Gil asked why Serval chose to go after ServiceNow rather than another enterprise giant. Stauch says ServiceNow is at heart a workflow automation platform, and AI coding makes code-based automation available to people who couldn't write it before.
…you end up making so many different decisions if you're building for the large enterprise from day one. All the product decisions, how you build your team, how you think about growth, they're fundamentally different than if you go and you serve one market and then you hope to expand later on.
How'd you choose this versus Salesforce? You know, there's a few other sort of canonical giant companies in different categories. I
think we didn't really understand. understand how we'd beat the other companies and why we had an advantage and what AI unlocked that they couldn't catch up to. And what we understood about ServiceNow because of our experience with IT is that fundamentally it is a workflow automation platform. And our belief, me and my co-founder and my co-founder really had this idea early on that code was the right way to express automation in the enterprise, that you should just build all automations and code. And these drag and drop workflow builders is a painful level of abstraction because it's too complex for non-technical users and it's annoyingly abstracted for technical users. Code is a better way of building automations. The problem, obviously, is not many people can write code and do it quickly enough for it to make sense for automation. And so as AI made this possible, that was what it clicked for both of us, that actually, if code is the right way to build automation and now anyone can write code, we can build a better automation platform. And what is an automation platform is actually what is the best market for an automation platform? It's actually taking on these massive legacy software…
guess two and a half years ago when you got started, though, most of the coding stuff was sort of tap complete. It did not work.
Yeah. And so they're very clear. Like, this is a brilliant idea. But in practice, when we started building this,
what was the assumption? Was it that the coding would get much better? Was it that you'd build tooling and then you didn't need to because things got so good? I'm sort of curious of that transition.