There is a moment in every online purchase across Africa that decides everything: the customer has already found the product, compared the price, made peace with the cost, and clicked to pay. What happens in the next few seconds, whether the page loads, whether the network holds, whether the form asks one question too many, determines if that decision survives contact with reality. Ojonugwa Martins Onogu has spent the better part of his career living inside that moment, and he talks about it the way a surgeon talks about the seconds after an incision: with precision, and without romance.
“Performance optimisation should always be driven by evidence, not intuition,” he tells me, and the sentence carries the weight of someone who has learned it the hard way, on a live product, with real money and real customers watching from unstable mobile networks in Lagos, Nairobi, and beyond.
Onogu is a software engineer, frontend-focused, and his working life has been shaped by one recurring assignment: fix the place where trust either forms or collapses. Across fintech platforms, merchant checkouts, and now AI-powered learning products, his name attaches itself to the unglamorous middle of digital commerce, the part users never think about when it works and never forgive when it doesn’t.
A SCIENTIST WHO BECAME AN ENGINEER
His path into software was not the straight line the industry likes to advertise. Onogu trained first as a scientist, a Bachelor of Science in Microbiology from Kogi State University, followed by a Master of Science in Epidemiology from the University of Ibadan. It is an unusual runway into frontend engineering, and it shows up in how he works more than in what he says about it. Epidemiology, at its core, is a discipline of pattern recognition under uncertainty: where is the friction entering the system, what is the vector, what intervention actually changes the outcome. Onogu never frames his engineering practice in those terms outright, but the instinct is recognisable. He does not begin with code. He begins with a question and a body of evidence.
That habit became the spine of the project he is best known for in engineering circles: the redesign of a checkout experience for an e-commerce platform serving customers across Africa, a system built to support card payments, USSD, bank transfers, and regional providers like Flutterwave, Paystack, and mobile money services such as M-Pesa, depending on where the customer happened to be shopping from.
WHERE THE MONEY WAS BEING LOST
The brief was, in his words, straightforward: improve checkout performance, increase successful payment completion, build reusable components that could support multiple payment providers, hold the line on accessibility and security, and design an architecture that would not buckle every time a new payment method entered the market. What was not straightforward was the checkout itself, which had accumulated the kind of technical debt that any system evolves when it grows faster than it is maintained.
“Like many applications that have evolved over time, the checkout experience had accumulated technical debt,” he says. Large JavaScript bundles were delaying the first paint. Components were re-rendering for no reason. The same API requests were firing twice. Every payment provider, card, USSD, bank transfer, mobile money, had built its own duplicated version of validation, loading states, and error handling. Customers could still complete a purchase, mostly, but the friction was concentrated exactly where African e-commerce is most vulnerable: on mobile devices, over slower networks, in markets where a few extra seconds of loading is not an inconvenience but a reason to abandon the cart entirely.
Before writing a line of new code, Onogu’s team profiled the application using Chrome DevTools, React Developer Tools, Lighthouse, and the React Profiler. “Understanding where users experienced delays proved far more valuable than making assumptions about performance bottlenecks,” he says, and it is a line that could sit comfortably in a research methodology chapter as easily as an engineering postmortem.
THE DISCIPLINE OF SUBTRACTION
The fix that mattered most was, in a sense, an act of restraint. The checkout had been bundling every payment provider’s code upfront, whether or not a given customer would ever touch USSD or mobile money. Onogu’s team introduced dynamic imports through Next.js so that each provider’s component loaded only when a customer actually selected it. Smaller bundles. Faster first paint. Less JavaScript sitting idle in a browser on a mid-range Android phone in a low-signal area.
“One of the most effective ways to improve performance is not by making code faster but by avoiding work altogether,” he says, and the line reads like a philosophy dressed as a technical note.
The architecture followed the same logic outward. Instead of each payment method reinventing its own interface, the team broke the checkout into composable, single-responsibility components: a payment form, a method selector, dedicated inputs for cards, mobile money, USSD, and bank transfer, shared billing, order summary, and error handling sitting underneath all of them. State, once scattered across individual components and difficult to trace, was centralised with Redux Toolkit. “State management should reduce complexity, not introduce it,” he says. “The best architecture is often the simplest one that can comfortably support future growth.”
Underneath the componentry, there was equal attention paid to network behaviour, caching requests, killing duplicate calls, memoising expensive renders, deferring non-critical scripts, trimming the arithmetic happening mid-render. None of it was dramatic on its own. Together, it cut frontend processing time by roughly fifteen percent.
WHAT GETS BUILT WHEN NOBODY IS WATCHING
Two threads run through Onogu’s account of the work that are easy to underrate because they rarely show up in a product demo: accessibility and security. The checkout was rebuilt with semantic HTML, keyboard navigation, ARIA labelling, visible focus states, and improved colour contrast, moving it toward WCAG compliance. “Performance means very little if customers cannot complete the checkout independently,” he says. On the security side, the frontend validated input before submission, guarded against common XSS vulnerabilities, avoided storing sensitive payment data client-side, enforced HTTPS, and handled authentication tokens with care. “Security should never be treated as a final testing phase,” he says. “It should influence architectural decisions from the beginning of a project.”
It is worth sitting with why this matters specifically for African e-commerce, and not as a generic engineering virtue. The payment landscape across the continent is fragmented by design, a single checkout might need to gracefully hand a customer between a card network, a USSD prompt, a bank transfer reference, and a mobile money wallet, often within the same market. Networks are inconsistent. Devices vary widely in processing power. Trust in digital payment systems is still being built, transaction by transaction, in economies where a failed or confusing checkout can undo months of a merchant’s marketing spend in a single afternoon. An architecture that quietly absorbs that complexity, rather than passing it on to the customer as friction, is not a cosmetic improvement. It is closer to infrastructure.
RESULTS, AND WHAT THEY ACTUALLY MEASURE
Following deployment, Onogu’s team recorded an approximately twenty percent increase in successful payment completions, alongside faster, more consistent frontend performance across multiple products. Earlier in his career, at a fintech building embedded payment solutions for merchant platforms, a similarly reusable checkout contributed to a fifteen percent lift in completed transactions, a twenty-five percent drop in transaction-related security incidents, and roughly fifteen percent faster page loads. The numbers repeat across his résumé not because the metrics are interchangeable, but because the underlying discipline is the same: identify where the customer is losing patience or trust, and remove it.
He is careful not to let the technology take credit that belongs to the thinking behind it. “The biggest lesson from this project wasn’t that React or Next.js can build fast applications,” he says. “Modern frameworks already provide excellent performance. The real challenge lies in making engineering decisions that improve business outcomes.” Every choice, dynamic imports, reusable components, centralised state, accessibility, testing, existed to serve one instruction: reduce customer friction. “Performance metrics matter,” he says, “but business metrics matter more.”
A PRINCIPLE, NOT A PORTFOLIO PIECE
Onogu writes as much as he builds, contributing technical essays to Medium and Cresta Africa on the mindset shift from framework fluency to product thinking, and on why performance deserves to be treated as a feature rather than an afterthought.
That instinct to hand knowledge back extends into a more formal commitment. Onogu has served as a mentor on Regenate’s tech mentorship programme across its software engineering track for three consecutive cohorts, 2023, 2024, and 2025, guiding early-career engineers through the same discipline that shapes his own work: evidence over assumption, architecture over shortcuts, and the patience to trace a problem to its actual source before touching a single line of code.
What stays with me, after going through his account of the checkout rebuild, is not the percentage gains, though they are real and they matter to the businesses that depend on them. It is the instinct underneath the work, the same one that likely served him in a laboratory before it served him in a codebase: distrust assumption, chase evidence, and treat the user’s patience as a finite, precious resource that engineering either protects or spends.
As digital payments continue to expand across African markets, layered with new providers, new regulatory demands, and increasingly capable but unevenly distributed devices, the kind of frontend engineering Onogu describes stops being a technical specialty and starts becoming a competitive one. Businesses that treat checkout as a solved problem will keep losing customers in the final seconds before a sale. Those that treat it the way Onogu does, as a place where architecture, empathy, and evidence have to meet, will keep the ones who almost walked away.
“Great frontend engineering isn’t measured by how much code we write,” he says, closing the thought the way he opened it, without ornament. “It’s measured by how effortlessly users achieve their goals.”
