Quick Fire 🔥 with Opeyemi Folorunsho

Opeyemi Folorunsho is the Vice President of Research and Development (R&D) at Moniepoint, where he focuses on translating deep technical ideas into systems that deliver real-world impact. His background is in distributed systems and infrastructure, and his work sits at the intersection of research and execution: identifying emerging opportunities, rigorously validating them, and building the platforms that bring them to life.

His core belief is that great engineering culture and first-principles thinking are what separate real innovation from trend-chasing. Over time, his focus has evolved from building systems to shaping their direction, guiding teams, setting the technical vision, and ensuring that research efforts translate into meaningful outcomes.

• Explain your job to a five-year-old.

Imagine you have a huge toy city where millions of people are playing every day. My job is to invent better roads, stronger bridges, and smarter traffic lights before the city gets too busy.

Sometimes I build new things myself. Sometimes I help other engineers build them. And sometimes I spend weeks figuring out a better way to solve a problem that nobody has solved before. My job is really to make sure the city keeps working even when millions more people arrive.

• What does R&D at a fintech actually look like day-to-day?

People often imagine R&D as scientists in a lab. In reality, it’s much closer to applied engineering.

A typical week involves understanding a difficult business problem, reading papers or technical documentation, evaluating existing technologies, building prototypes, measuring trade-offs, and deciding whether an idea deserves to become part of the production platform.

Some projects never leave the prototype stage because the economics don’t work. Others end up becoming core infrastructure that every engineering team depends on.

At Moniepoint, that has meant exploring technologies like distributed databases, stream processing, developer platforms, fraud detection techniques, infrastructure automation, and ways to simplify how engineers build products at scale.

The goal isn’t research for its own sake. It’s reducing uncertainty so the business can make better engineering decisions.

• How do you decide when an idea is ready to become a product?

I look for three things. First, have we actually solved the hard technical problems, or have we only built a good demo? Second, does the solution reduce complexity instead of adding it? A prototype can tolerate cleverness. A production system cannot. Third, does it solve a real problem that multiple teams have? If only one engineer understands it or only one team benefits from it, it’s probably still research.

The transition happens when the unknowns become known. At that point, the work shifts from discovering whether something is possible to making it reliable, maintainable, and easy for other engineers to use.

• Moniepoint has scaled aggressively across Africa. What does that kind of growth demand from an infrastructure standpoint?

Growth changes the questions you ask. Early on, you’re asking, “Can we make this work?” Later, you’re asking, “Can this survive ten times the traffic without waking someone up at 3 a.m.?”

At Moniepoint, operating at scale means designing systems that can handle billions of financial events, maintain low latency, recover gracefully from failures, and continue operating across different regions and varying network conditions.

It also means investing heavily in internal platforms. As an engineering organisation grows, developer productivity becomes an infrastructure problem too. Good tooling, automation, observability, deployment systems, and standardised platforms allow hundreds of engineers to move quickly without compromising reliability. The infrastructure isn’t just supporting the business anymore. It becomes a competitive advantage.

• What’s the biggest misconception engineers have about what good research looks like?

Many engineers think research is about reading papers. It isn’t. Good research is about reducing uncertainty.

Sometimes that means reading academic papers. More often, it means building prototypes, collecting evidence, measuring performance, talking to users, and being willing to prove your own idea wrong.

The best outcome in R&D isn’t proving you’re right. It’s learning something valuable before the company spends months building the wrong thing. Research should make future engineering easier, not more complicated.

• What did your path to VP of R&D look like, and what would you do differently if you were starting over?

My career has always been driven more by curiosity than by titles. I naturally gravitated toward difficult infrastructure problems, distributed systems, databases, developer platforms, and the kind of engineering work where understanding the internals makes a real difference. Over time, that evolved from solving technical problems myself to helping teams identify which problems were worth solving in the first place.

As I moved into leadership, I realised that R&D isn’t just about technology. It’s about creating a process that turns uncertainty into informed decisions. Today, a large part of my role is helping the organization explore new ideas while ensuring the successful ones can be handed over to product teams and scaled across the business.

If I were starting over, I would spend less time chasing individual technologies and more time learning systems thinking, communication, and economics. Languages, frameworks, and databases come and go. The ability to reason about complex systems, communicate clearly, and understand the business value behind technical decisions compounds over an entire career. Those skills have mattered far more than any particular technology I’ve learned.