With Olumide Ogunsanwo – Co-host, Afrobility & GP, Adamandium Fund

A few weeks ago, I (Justin) was spending time with a fintech founder, who complained about the reliability of one of its partners. That same week, I was with another fintech founder, who shared a story of another partner that kept pushing back the availability of a product launch that was core to the company’s service offering. Later, I got emails from two different consumer fintechs, saying that a feature of their app was not currently available due to its partners, as well. And just this week, several other fintechs announced the unavailability of their virtual cards due to the temporary suspension of services by Union54.

In TFN #76, I wrote about specialization, and the increased proliferation of API-first, B2B infrastructure companies building at one layer of a given value chain. The promise of API-first companies is not only that they make it easier to build – it was much harder to start an online business before Stripe in the US or Paystack in Nigeria – but that through their specialization and narrow focus, these companies build best-in-class solutions for their customers.

Specialization is a function of focus and scale. API-first companies are able to justify small improvements – Shola Akinlade told me in an interview after Stripe’s acquisition of Paystack that their focus is improving their transaction success from 99 to 99.9 percent – and the amount of customers they serve allows them to build a large and profitable business around such a narrow focus. Likewise, if fraud is a pervasive issue with virtual cards, it’s likely only the specialists with the expertise (and the focus, and the resources) to solve that problem.

On one hand, we’ve seen more API-first specialists emerge in the African tech ecosystem. The Flip’s season three episode, Africa Stack, explored specialists building in payments, data, and identity.

On the other hand, we’ve still seen several examples of startups – in fintech and otherwise – building out more of the stack themselves. Indeed, doing so may allow them to capture more value, but it’s largely and primarily a function of necessity. When the reliability of your third-party providers is in doubt, what choice do companies have?

That was the dilemma I was hoping Olumide could help me to reconcile…

From an investor point of view, this is an important part of due diligence. What tech stack is a company built on top of, and to what extent is the reliability of third-party providers going to be a problem? But startup dependencies run even deeper.

Startup dependencies on partners (that provide features, functionality, access to customers, and so on) can generally take two forms:

1. Partners that provide features that are mature and (mostly) work.
2. Partners that provide features that are early so may have growing pains.

An example of the first form: startups need to send messages (OTPs, account opening messages, customer support messages, marketing messages, etc.) to their end customers through cPaas (Communications Platform as a Service). Platforms such as Africa’s Talking and Termii seem to have a good reputation for reliably delivering messages. The proliferation and maturation of infrastructure that falls in this first bucket have played an outsized role in the scale of the ecosystem.

An example of the second form: part of the reason ecommerce in Nigeria has been a harder challenge than many would have expected is that Konga and Jumia did not have warehousing and logistics partners to work with and eventually had to build a lot of this themselves (see here, here and here). Like what we’re seeing with virtual card services today, functionality may be early and evolving.

Similarly, many startups (especially FinTechs) see lending to end consumers, SMEs and other businesses as an important way to monetize. Sustainable lending requires risk assessment data which can be collected by the startups themselves (first-party data), from other sources (third-party), or a combination of both.

The choice of using 1P data vs 3P data largely boils down to the trade-off between speed & moat creation. The startup can run/launch/scale fast if they use 3P providers but will have a thin moat as another startup player can plugin into the same 3P providers and launch a similar service.

Alternatively, using 1P data may lead to a more reliable moat but may take longer to build. This is one of the many reasons why building a startup is difficult, founders are faced with these never-ending decisions as the company grows.

Here’s another example: Kuda historically seems to build more in-house (it built its own custom core banking application but could have used Woodcore or Appzone). After a switch away from a 3P to its own 1P core banking application, Kuda said, “Since we moved to Nerve, our dependency on third parties has reduced significantly, transfers have become more reliable and we’ve been able to sign up more people easily.”

Alternatively, Kuda could also decide to expand its lending business by using 3P API credit assessment services (e.g., CreditChek which in full disclosure is an Adamantium Fund portfolio company). These credit assessment companies would provide Kuda with information from a wide variety of sources (e.g., Credit Bureau data). This 3P integration would allow Kuda to scale faster versus the alternative of directly integrating with the National credit bureaus (i.e. the real world).

All startups eventually lead to some real-world interaction. The question for founders to consider is: Is my startup best positioned to do the messy work of interacting with the underlying real-world infrastructure or should I find trusted partners and focus on my core business?