TL;DR
API consultant Daniel Kocot argues that API success hinges less on frameworks and more on people. In this episode, he joins Jens and Stefan to call out why teams keep adding tools without asking basic questions, how capability thinking can cut through confusion between business and engineering, and why new hypes like MCP just pile complexity on top of existing messes.
Consulting in a Post-Remote World
Daniel began by contrasting on-site consulting with remote work. Remote is fine for deep focus tasks, but relationships and trust are built in person.
Sometimes you meet someone on accident, it was not planned. That can’t happen remotely.
For him, consulting is not just about deliverables, but about building enough trust to navigate enterprise politics, align on language, and push long-term changes.
Remote makes it easy to switch cameras off or disengage, he noted. On-site, you bump into people you wouldn’t normally meet, share meals, and pick up on unspoken reactions. Those moments deepen trust and help projects move forward.
Why APIs Are a People Problem
Daniel traced his path from Atlassian projects into API consulting. The lesson: technology is rarely the blocker.
Technically everything is actually solved. What’s missing is the connection—people don’t ask why an API exists or how it links to business goals.
He sees tutorials and frameworks give the illusion of progress, but without strategy or shared understanding, companies end up with “API sprawl.”
REST, GraphQL, and Patterns Beyond Technology
The hosts asked how REST has evolved. Daniel echoed Kevin Swiber's view that many teams reduce REST to “JSON over HTTP.” To cut through the noise, he uses interaction patterns: resource, tunnel (RPC/gRPC), query (GraphQL), and event.
It’s better to describe what you need as a capability than to fight over terms like REST or events.
This framing helps non-technical stakeholders see the value without getting lost in protocol debates.
Capability Thinking and Governance Gaps
Governance came up as a consistent failure point. Many enterprises install gateways or management tools without clear purpose. He added that even simple practices like linting API descriptions or running end-to-end tests still surprise some enterprises.
A gateway is not an architectural tool, it’s an infrastructure tool. Without use cases, it doesn’t solve governance.
Daniel pointed to capability thinking as a way to bridge business and technical views. Instead of listing endpoints, teams define what a capability delivers in plain terms, making APIs searchable and understandable.
A Surprising Stack
Not all widely used APIs are built on mainstream stacks. Daniel recalled one story that stuck with him.
There was an API built with R… and it was the most used API there.
As he put it, “you can use every framework to build APIs.” The surprise wasn’t the language, but that it became the company’s most used API. It was a reminder that usefulness matters more than stack choice.
AI, MCP, and the Next Hype Cycle
When asked about AI and the Model Context Protocol (MCP), Daniel was cautious.
“People are still suffering from the APIs they already have. Why should they then have an MCP to make 1000 APIs available by one call?”
He sees potential in AI helping to map requirements to capabilities, but warns that it cannot substitute for governance or strategy. Hype, he noted, tends to move faster than real adoption.
This episode was directed by Jacob Javor. Transcript lightly edited for clarity and flow.
