The API-First Trap: How Fipto Learned That Selling APIs is Harder Than Building Them

In a recent episode of Category Visionaries, Patrick Mollard, CEO and Co-Founder of Fipto, a blockchain payments platform that’s raised $16 million, shared a lesson that most technical founders learn the hard way: elegant architecture doesn’t guarantee commercial traction. Fipto built sophisticated APIs that solved real payment problems. Then they discovered nobody wanted to buy them.

The Architectural Purity of API-First

Fipto’s initial product strategy made perfect sense on paper. They were building blockchain payment infrastructure for corporate clients who already had systems in place—treasury management platforms, ERPs, existing payment workflows. The logical approach: integrate into those systems via API.

“We started by building the solution as an API first solution,” Patrick explains. They developed three core APIs, each targeting a specific pain point in blockchain payments. The first API enabled clients to “open wallets in the coins and tokens they want to use to make their payments. And also obviously IBN accounts in euros to be able to send us the funds in order to use cryptocurrencies afterwards.”

The second API handled conversion—moving from one token or currency to another. The third focused on the actual payment flows: “receiving and sending funds out of these wallets and accounts.”

From a technical standpoint, this was sound infrastructure design. Each API had a clear purpose. The separation of concerns was clean. Integration points were well-defined. For a team where two-thirds of the 30-person company focuses on product and tech, this was the kind of elegant solution you’d want to build.

The problem? APIs don’t sell themselves.

The Commercial Reality Check

Patrick is direct about what happened next: “We realized that actually selling an API is very difficult.”

This realization cuts to the core of a common founder trap. Technical founders often assume that if they build something technically excellent that solves a real problem, adoption will follow naturally. API-first strategies amplify this trap because they feel so obviously correct for infrastructure products.

But selling APIs requires customers who already understand they need your specific solution and have engineering resources allocated to integration work. For an emerging category like blockchain payments, that’s a narrow wedge. Most potential customers are still figuring out whether they should use blockchain for payments, let alone which specific API they need and how to integrate it.

APIs also create friction in the sales process. There’s no way to demo value without integration work. There’s no trial period that doesn’t require developer time. There’s no way for a decision-maker to “see” the product working without technical implementation first. In early-stage categories, this friction kills deals.

The Platform as First Customer

Fipto’s solution preserved their API-first architecture while solving the sales problem: “We developed a platform that is the first client of our APIs.”

This wasn’t a compromise or a failure of vision. It was strategic sequencing. The platform gave them something they could actually sell—a complete product with a user interface, onboarding flow, and immediate value demonstration. No integration required. No developer resources needed. A sales prospect could sign up, see the platform work, and become a paying customer.

But the platform wasn’t the end goal. Patrick is clear about this: “The logic behind that is that we are convinced that in the end, our ideal go to market strategy is to be able to integrate our APIs into third party systems and softwares that are actually used by corporate clients.”

The platform creates a flywheel. Direct platform sales generate revenue, which funds further development. Those customers become case studies and reference accounts. That traction makes conversations with larger partners more credible. “For us, treasury management systems are great targets and we are actually working today with Kiriba to integrate our solutions in their solutions,” Patrick notes.

Kyriba isn’t integrating Fipto’s APIs because the APIs are elegant. They’re considering integration because Fipto has proven commercial traction with real customers processing real payments through the platform. The platform validates that the APIs solve problems people will pay for.

Why This Pattern Repeats

The API-first trap catches technical founders repeatedly because the logic seems unassailable. You’re building infrastructure. Your customers have existing systems. APIs are the “right” way to integrate. All true. But it ignores the commercial reality of early-stage categories.

When you’re creating a new category or bringing emerging technology to established markets, education precedes adoption. Potential customers need to understand the problem, believe in the solution approach, and see proof that it works before they’ll commit engineering resources to integration.

A platform provides that proof. It shows the value working end-to-end. It generates revenue that validates product-market fit. It creates customers who can speak credibly about results. Only then do larger partners take API integration seriously.

Patrick’s experience reveals the underlying principle: in emerging categories, you need direct product revenue before you can successfully pursue platform distribution through APIs. The platform isn’t a detour from the API strategy—it’s the enabler of it.

The Integration Strategy That Actually Works

Fipto’s current approach combines both motions strategically. They sell the platform directly to generate revenue and prove value. Simultaneously, they use that traction to pursue integration partnerships with systems like Kyriba where their target customers already work.

“That’s the idea. But again, we built a platform to be able to sell it to customers in order to convince the players like Kiriba and other TMSs and potentially ERPs that they should actually integrate us,” Patrick explains. “And yeah, from our experience, that’s the only way to go.”

That final phrase—”the only way to go”—reflects hard-won experience. It’s not theoretical product strategy. It’s what they learned by trying to sell APIs directly, discovering the friction, and adapting their approach while maintaining their long-term vision.

When APIs Work as Primary Products

The API-first approach isn’t wrong for every infrastructure company. It works when you’re selling to customers who already know they need your specific solution. Stripe succeeded with API-first because developers already knew they needed payment processing and were actively searching for implementation options. Twilio won with APIs because developers had a clear requirement to add SMS or voice capabilities to existing applications.

But Fipto isn’t selling to a market that already knows it needs blockchain payment APIs. They’re creating that market. The difference is crucial. In mature problem spaces, APIs reduce friction. In emerging categories, they add it.

The Broader Lesson for Infrastructure Founders

Patrick’s journey offers a framework for infrastructure companies in emerging categories. Start with clear architectural vision—know what the API layer should look like long-term. But don’t confuse good architecture with good go-to-market strategy.

Build a direct product that can generate revenue without requiring integration work. Use that product to prove market demand, generate case studies, and fund development. Then leverage that traction to pursue the integration partnerships that enable platform-scale distribution.

The platform isn’t the consolation prize when your API strategy fails. It’s the proof point that makes your API strategy viable. Technical excellence creates the potential for commercial success. But commercial traction—revenue from real customers with real problems—creates the foundation for platform distribution.

Fipto built elegant APIs that solved important problems. But they didn’t start generating revenue until they built a platform that could sell itself. That’s the gap between technical excellence and commercial viability—and it’s a gap that founders need to bridge with product strategy, not just better engineering.