For the love of APIs!

The irony of geeking out on random things is that your mind can suddenly latch onto something, an idea, a seeming pattern, a figment of your imagination, and get stuck there, so much that you can’t seem to ‘unlatch’.

Sometime last year, I had one of those unlatching moments, I like to call those moments – the OG of ‘circling back’. My friend, Ayo Onasanya, who is the Founder of Acumen Digital, had built a number of products and I couldn’t seem to shake the fact that I saw a pattern in a couple of the products.

In July, it dawned on me that damn! he had built a number of API-led products: Tendar, Karla, Robin, and I became obsessively fascinated by that. I wondered why he had chosen this route for building his products? Was it happenstance or did he see it as a route to solving problems? A couple of thinking hours later, I was in a rabbit hole.
When I first tumbled down this rabbit hole, I had prompted why on earth it’d be a business obsession:

Chatjibiti aside, what are APIs?

APIs help different apps and services work together by letting them share data and features in a standard way. They make it easy for one system to connect with another without needing to understand all the details of how it works. This is why many apps today can talk to each other seamlessly, from payment systems to social media.

When describing what an API is to a novice or a child, I like to use the mental image of ‘call and response’. If you were ever in a children’s choir, you’d get it immediately.
A good example (for an adult) would be using a digital wallet app like Moniepoint, Cash App, or Chipper Cash to send money to a friend. Several APIs work in the background to make this happen:

• Banking API (for Account Verification): When you sign up and link your bank account, the app uses a banking API (like Plaid or Mono) to securely verify your account details without needing you to manually enter everything.
• Identity Verification API: If the app needs to verify your identity (to comply with KYC regulations), it might use an ID verification API like Onfido or Smile Identity to check your government-issued ID against a database.
• Payment API (for Money Transfer): When you send money, the app connects to a payment processing API (like Paystack, Flutterwave, or Stripe) to securely transfer funds from your account to your friend’s account.
• Currency Exchange API (if sending money internationally): If you’re sending money across borders, the app might use a currency exchange API (like Open Exchange Rates or XE) to convert your money at the current exchange rate before transferring it.
• Fraud Detection API: To keep transactions secure, the app may use a fraud detection API (like Sift or Feedzai) to analyze transaction patterns and flag suspicious activity.
• SMS/Email Notification API: Once the transaction is complete, the app might use Twilio or SendGrid APIs to send you and your friend a confirmation via SMS or email.

Each of these APIs allows the ride-sharing app to provide a smooth experience without building all these services from scratch. Instead of creating their own maps, payment system, or messaging service, they use APIs to connect with existing tools.

I also find Adam Xavier’s well-illustrated piece from 2019 to be a great resource for breaking down the concept.

“Building an API-led business is like building roads, bridges, and power grids for the Internet..”

Back to the matter.

I reached out to Ayo to ask him about what I had noticed and we got talking, diving into his why.
Why do you go this route of creating APIs? What’s the reason for using this particular stack? Were you fascinated by something?. 

That’s a good question and thought process. Some problems need to be solved in certain ways – there’s a saying that “we cannot solve our problems with the same thinking we used to create them”  So, you have to think at a higher degree, and scale as well, right? For me, I was thinking about solving a problem for multiple people – I can be quite obsessive about use-case scenarios.

Scenarios…

For example, WordPress, or Wix, solved the problem of people who want to create websites, but aren’t technical.
And so, they’ve done a great job of allowing people to have a drag-and-drop type of solution. They’ve therefore built for the end users, while at the same time building for someone who is technical and can really just go into WordPress and not even touch any drag and drop at all, and they will create a really sweet website out of it, right?
That’s the approach and the thinking around most of the products and tools that we’re building.

I’m focused on building tools that empower people to start businesses or streamline operations without needing prior knowledge. For example, with our product, Tendar, a mortgage/lending company that previously managed everything manually, can now automate tasks like qualifying clients, checking their bank statements, and automating monthly mortgage collections.

…that are Scalable

First off, it’s, like, we’re building it so that somebody else who is also a builder, like ourselves, can go there and create anything beyond what we’ve thought about.

The solutions are led by how scalable is this thing. Can I take it out of the country? Or a new territory altogether and the system is still valuable?
I like to think along the lines of being flexible and able to integrate with local players while retaining structural integrity.

Think about your Microsoft Office today, you have to install it on your Mac, it’s therefore local to you. But when Google Docs came, it enabled other things. The same set of solutions, but the approach is different. Google Docs built it more from, like, a scale perspective, right? And they even have, API documentation, you can build plugins into it.
So, same thing with Figma, right? Before Figma came, we were all using Photoshop to do website design and UX design. I could go on and on.

…and are developer-led

The third thing (we weren’t counting before, but somehow, I’ve numbered this to third in an imaginary list) is a developer community. Some of my favourite products out there are developer community-led, it’s naturally become a part of the thinking behind what we build. I love the energy that comes with enabling developers to participate in your product development. Now it’s no longer you developing it. You’ve developed the core. You’re now telling people, you’ve created a guideline, too, and say, okay, if you want to build anything, follow these guidelines, build it, submit it, and then we’ll approve it.

So, now, people are building things for their own use cases, but they’re also solving thousands and millions of problems for other people. And then that makes your product really strong because they were solving their problem, and giving you insights and fresh perspectives to new problems.

Where you can literally create a plugin. Say you can translate or build an AI or an engine that can translate English to Yoruba, right? You can package that as a plugin and put it on the Figma community. Other designers will find it and install it. Mostly the ones designing for that language.

In summary, I’d say my leaning towards API-led solutions is a combination of 2 thought processes: “I want this to really scale, from a monetary value, being able to use it across, any markets, any country, and then scale from point of view of the user base as well.”
And developer-led products are usually, like, as long as the developer experience is good, right, like, it’s always one of those easy things. it’s a system that works, essentially.