The Superface Story
This is what happened.
I keep being right too early. I helped invent how the modern world describes APIs, built developer tooling that thousands loved, and designed a platform that connects to APIs automatically — then watched other people collect the money. Every time, a few years too soon.
This is the story of three companies, one idea I couldn’t let go of, and the long gap between being first and being right.
I’m going to blame timing for that gap — a lot. Watch me lean on it. Some of the gap was the market; some of it was me.
Apiary
At Apiary (circa 2011-2017), I built the API Blueprint — a markdown-based format for describing APIs. We shaped modern API design, and pioneered API-first and API-lifecycle approaches to building APIs. Design, prototype, verify, build, test, monitor… We were THE format, loved and used by thousands, but we only ever found a weak monetization path, in API governance. Luckily for Apiary, Oracle needed API thought-leadership and street credibility, and acquired Apiary right when Swagger was getting back to the spotlight after entering Linux Foundation and rebranding itself as OpenAPI…
Hindsight: OpenAPI matured around 2022 and Smartbear was able to make significant revenue on API design from 2020+.
Good API
During the merger (2017) I left Apiary and started Good API boutique consulting, helping the best European enterprises to define and execute their API programs. Later, Erik Wilde and Adam Kliment joined me, and together we ruled enterprise API programs in the EU — albeit briefly. Adidas/Herzogenaurach, DHL Group/Bonn, Inditex/A Coruña, VW Group/Wolfsburg are some of the companies we worked with.
When COVID hit the world (2020), every single client failed and panicked. Some left immediately, some later. Honestly? It felt like permission. Consulting wears you down — every new client a new company to learn, new relationships from zero, over and over. The people were the best part — I still miss the friends I made along the way. But after enough times I knew it wasn’t the long game.
Autonomous APIs
No clients? Cool. I wanted to do this new thing anyway. I was experimenting with ALPS (Mike Amundsen, Mark Foster, and Leonard Richardson) which led me to the invention of the “proxyless API integration pattern” (that later materialized in Superface’s OneSDK 1).
Since late 2016, I had been working on the idea of “Autonomous APIs” — both as the answer to the complexity of API integration, and, perhaps more important, a way for businesses to integrate and transact over APIs automatically 2. Technically, Autonomous API implementation utilized proxyless integration and autonomous service discovery, alongside a marketplace of capabilities (inspired by the Universe of Capabilities of Dag Kittlaus) and a contracting layer.
Hindsight: I was early 6 years at the minimum (MCP marketplaces, Agentic Commerce, Agentic B2B)
Superface
Following the loss of all of Good API’s customers, and fueled by excitement about Autonomous APIs, I approached my friend Radek (who had just left his startup MyStay) with the idea of solving “the integration problem” once and for all. He said yes, and we became co-founders.
Radek experienced the pain (costs and time) of integrations when he wanted to integrate his startup with hospitality systems including Booking.com.
For me, the weight of API integrations first manifested at Adidas when I saw both Adidas and Intersport (large sporting goods retail chain) teams arguing who integrates who, who should bear the burden of the integration — will Adidas integrate Intersport APIs because they want to sell to them or will Intersport integrate Adidas APIs because they want to sell their goods?
That lesson was cemented later, when I designed the best-in-class, hypermedia REST APIs for DHL Express. They were beautiful — and useless until your business representatives (and lawyers) had met and negotiated for weeks.
APIs seem like machine-to-machine communication, but the reality is you need dozens of people to connect the machines together. Mechanical Turk.
Time to change this.
Hindsight: The problem of getting API access is still not solved, and is one of the main hurdles for fully autonomous agentic AI (as of Summer 2026).
Autonomous API integration & B2B
We founded Superface (super-interface) in 2020. The vision was strong: Autonomous API integration, autonomous business on top of APIs. Marketplace of capabilities. Businesses contracting other businesses, autonomously integrating their APIs in milliseconds, switching suppliers as needed.
The path to revenue was the exact opposite — unclear and bleak. The go-to-market? Bottom up. We have the proxyless integration technology that every developer would love to adopt, right? But then, even if they would, if Apiary taught us something, it was developers != money.
Writing this sitting on a plane to my beloved SF, I can’t help thinking of the Heavybit developer guild (Apiary was part of it) — founded by a Heroku founder James Lindenbaum on the thesis that developer tooling startups can be viable and make money.
Ironically, the first projects that truly pull the money from developers’ pockets arrived only in late 2025: Anthropic and OpenAI…
So we walked the path I already knew from Apiary — bottom up, through developers — and Superface embarked on an impossible journey: winning their attention with a black box that was solving nobody’s pain.
Technically, Superface’s proxyless solution depends on metadata (a new DSL I created — COMLINK) that abstracts the API into a business problem, and this metadata needed to be created manually.
It turned out that the effort to create that metadata manually was equal to or greater than manually integrating APIs. The new DSL had a steep learning curve and besides, nobody wants to spend time building reusable integrations that could then be utilized by the competition.
The sad realization was: Integrations are a burden but once you have them in place, they are your defensive moat against those who do not.
The no-proxy pattern and API-vendor-agnostic integration weren’t appealing value propositions either. Everybody seemed fine routing their integrations through an iPaaS or connector platforms like Composio or Merge. Furthermore, API vendors hated the idea they would be commoditized. Even small companies struggling against incumbents didn’t seem interested in competing on price or quality of their API services. They knew that once somebody spends the time and resources to integrate their APIs, they’re stuck with them.
The cost (and time) of integrations is both an obstacle and a defensive moat for API consumers and a stickiness for API vendors.
We’ve tried and failed to break this.
In this era, I also committed to one of my biggest mistakes at Superface — hiring too big a team too early, designer (the best one!), product owner, devrel, more developers, people building COMLINKs, all great people but almost everyone too soon — well before we could even think of a product market fit. So I had to lay them off — people I’d convinced to join me, who trusted me. Friends. They understood, and this is the part I still carry.
Automated API integration
We still saw the beauty and value in our core technology so we doubled down on it and started building an automated engine that integrates APIs — EDGAR.
At the same time, we started exploring going vertical versus being a horizontal integration platform for every API and everybody. But we lacked the vertical expertise where projects like Mews (hospitality), Metapack (logistics), Merge (CRM, HRIS) and others already provided vertically unified APIs.
Then GPT came …
….and I saw this as an opportunity, not a threat — we used it to quickly analyze API docs and create our metadata (COMLINKs) — EDGAR was finally working as we wanted and it was a marvel — you pointed EDGAR at an API’s documentation, stated what you want to do with that API, and a few moments later you had a working integration (I know what you are thinking, but this was 2022 — well over two years before Claude Code’s launch).
Later, when custom GPTs came out, we saw the gap: they needed to connect to APIs, and the only way to do it was to drop in an OpenAPI spec and hope it works.
We solved this with Superface + EDGAR. You hook your custom GPT with Superface and voilà, your GPT is connected to, say, Google Sheets while we also handle the authentication of your GPT users.
Our users loved this feature and kept using Superface for it. The “only” problem was that we could not see any meaningful monetization path of this feature (or upsell to other paid features).
Hindsight: Connecting GPTs and Claude to APIs for end users had no meaningful monetization path, no path towards our vision.
Automation Agent
Inevitably, we pivoted to building agents …
It was logical. We knew how to connect agents to APIs well — surely we could make agents do meaningful things.
Our first attempt was a chat-based agent called “POD”. There, you could automate your tasks and schedule them, for example “Get the latest market data and store them in a spreadsheet”. It worked well for flashy demos but nothing more.
Hindsight: Too early — it didn’t work reliably.
People who liked it were usually sales reps and their managers. It turned out nobody in sales organizations seemed to like to work with CRMs. A sales VP at a leading international healthcare company even stated that “Salesforce is a dirty word” amongst their reps. The pain was there.
First context-aware agent
Armed with this opportunity and our ability to connect to external systems we built “DANA” — a context-aware agent that knew how to react in certain situations (i.e. “I had a call with a prospect” or “a request for quote arrived”).
As with POD, demos were well received. But the gap between demo and production readiness was staggering. What worked a minute ago wasn’t working the next moment. Simple cases failing without apparent reasons, complex ones impossible to debug.
At the same time, we realized that most of our prospects were talking to us just to get a “free AI training” of what is possible and how to build their internal AI solutions — they weren’t ready to move and buy.
Hindsight: Too early — the market was only just shaping up.
Agentic reliability & Specialist agents
The frustration with poor reliability led us to (i) create a benchmark focused on agentic success rates to get the baseline numbers 3 , and (ii) develop the concept of specialist agents — self-contained agents built to work with a single system or task instead of using API connectors (e.g. HubSpot Specialist, CRM Specialist, New Sales Lead Specialist).
The research, led by Radek Kysely, hypothesized that a self-contained agent with a memory and a context, that progressively learns, will yield better results than a bunch of API connectors (or MCP tools) thrown at the main agent.
The benchmark results of specialists compared to the traditional connectors were promising. Our approach was reaching 70% agentic success rates compared to the baseline of 30% with API connectors. But once again, we were too early — the world of RAG, chatbots and gen AI did not care about agentic success rates.
Hindsight: Too early — not a pain in 2023–2024.
Agentic connectivity & governance platform
Running low on runway, we tried a top-down GTM, approaching companies in our network with what was then a weak pitch (though probably not anymore): we’ll make your agents work — and provide the connectivity and governance tissue for every agent in your company. The problem: it was 2024, and close to 0% of companies had a problem with agents.
Hindsight: Too early — not a pain in 2024–2025; only materializing in 2026, bundled into AI enterprise platforms.
Agentic wallet, commerce and payments
Running out of options, we tried a wild shot with agentic payments — after all, agents and MCP (marketplaces) together with the explosion of the agentic commerce protocols brought us closer to the ultimate vision of the autonomous B2B. Building on Circle’s chain, we created the “Apple Pay” for agents — enabling agents to pay autonomously for goods and services via x402 / UCP / ACP protocols.
And, yes — you guessed it — we were, once again, first — and late at the same time. Late in the life of a startup that after 5 years and over 4M USD raised failed to hit any meaningful product-market-fit…
Hindsight: Too early — not a pain in 2025–early 2026, and the company too dragged and exhausted by then.
The market is only just showing up. The connectivity layer and the governance around it — what Superface spent five years building — is now getting bundled into enterprise AI platforms, next to the AI gateways and runtimes.
First, and a few years early. Every time.
No grief, no shame — if anything, anger at myself. I wanted the idea to be real so badly that I ignored the market. The textbook mistake. I’d read the book.
And it wasn’t only the timing. Some of what we built, nobody could ever want: we were asking businesses to melt down the integrations that protected them. You don’t commoditize your customers’ moat.
And it wasn’t only the idea, either. Deep tech like this belongs in the Bay, not where we were. We couldn’t sell, couldn’t market. Life happened, to all of us. “Too early” was real — but it was also the easiest reason to reach for.
Radek and I argued our way through five years — go-to-market, who we were building for, what the product even was. We mostly went my direction; the vertical push and the CRM automation were the exceptions, and his.
We parted as friends — he’s onto his own things now.
I’m building again. Stealth, for now — and older about it.