How Ayodeji Moses Odukoya built a bridge from digital marketing to high-scale product engineering

In the world of modern software engineering, the title “Frontend Developer” often feels insufficient to describe the complexity of the role. For Ayodeji Moses Odukoya, the browser is not just a rendering target; it is a distributed computing environment that requires rigorous architecture.

From digital marketing and optimising engagement algorithms to creating cloud-native solutions for millions of users, Ayodeji built a career on the cutting edge of the JavaScript ecosystem. We sat down with him to discuss his technical journey: his “quality-first” philosophy using Playwright and why he believes the best frontend architectures are designed keeping in mind the backend.

Ayodeji: That was foundational. I did not write a line of production code before; I was obsessed with what makes a user stop scrolling. In 2017, the algorithms were different, but the core challenge was the same: connection. I remember managing a social strategy in which we were pulling more than 1,000 organic likes on posts when there was a follower base of under 5,000. That’s a 20% engagement rate, metrics that are almost unheard of today with no paid spend.

That experience, coupled with my Google Digital Skills certification, gave me a lens which most other people, including most engineers, don’t have. Today, when I look at any UI component, I don’t see a React prop; I see an interaction point. I know what is required to bring the user to that button, so that’s why I am so obsessed with making sure the technology will not fail them when they get there.

Ayodeji: It is a direct translation of intent. In 2016, I was optimising for “Likes” and “Shares” using psychological triggers. Today, I optimise for Largest Contentful Paint (LCP) and First Input Delay (FID).

My marketing background taught me that users are notoriously impatient. If a page takes 3 seconds to hydrate, you’ve lost the conversion. When I architect a frontend now, I utilise Next.js here, thus allowing rendering either by Server-Side Rendering or Static Site Generation. I am not just looking at code cleanliness; I’m looking into the critical rendering path. Utilising tools like Google Analytics data in the context of GA4 and Lighthouse to audit our performance budgets, correlating technical metrics like Time to Interactive (TTI) directly with the retention rates I used to chase as a marketer

• Q: You went from marketing into software via Ruby on Rails to frontend. How does knowledge of the backend (MVC patterns, DB schema) make you a better frontend developer?

Ayodeji: Learning Ruby on Rails initially gave me a structural discipline that, most of the time, is usually overlooked by many purely frontend developers. In Rails, you live and die by the MVC (Model-View-Controller) pattern.

Knowing the concepts of database normalisation and ORMs helps me handle the frontend by managing it in another way. Whenever I implement Redux Toolkit or the Context API, I am effectively designing a client-side database. I design the stores to be normalised, avoiding deep object nesting and data duplication, just like one would do in any regular SQL schema. This architectural rigour disallows the “prop-drilling” anti-pattern and saves us from forcing huge component trees to re-render just to update a single Boolean flag.

Ayodeji’s outsize impact at Conectar

Ayodeji: Scaling to a million users exposes every inefficiency in your bundle. In other words, volume can easily murder the main thread with O(n) operations in the render cycle. We had to be ruthless in performance optimisation. I led a migration toward component-driven development using StorybookJS. It allowed us to build, profile, and stress-test components in isolation before they ever touched the main application DOM.

We also used memoisation with useMemo and useCallback to keep referential equality and prevent unnecessary re-renders. We also added aggressive code-splitting and lazy loading at the route level, so our initial bundle size is minimal. The spotlight of “reusable, performant UI components” was the main driving force in increasing the user satisfaction metrics by 50%.

Ayodeji: Social commerce is architecturally demanding since it causes an “over-fetching” vs. “under-fetching” dilemma. You have a feed that appears like social media, but each item is a transaction waiting to happen.

With a traditional REST API, rendering a user’s feed with products, seller profiles, and inventory status would require multiple round trips or a massive, slow payload, the classic N+1 problem. Using GraphQL/Apollo Client, we defined a strict schema that allows the client to ask for that graph of data with a single request.

Moreover, Apollo’s normalised cache allowed us to implement Optimistic UI. Whenever a user “Likes” something, we instantly update the cache so that the UI will show the change instantly, while the mutation resolves in the background. That perceived performance is crucial to the boost in engagement that we were able to attain.

Ayodeji: Those days of “it works on my machine” are gone. I containerise our frontend applications, ensuring development environments are isomorphic in production. When deploying to AWS through Kubernetes, having a Dockerised frontend allows us to scale up events gracefully. In case of increased traffic, the orchestrator fires up additional instantly restarted frontend pods. 

Understanding the infrastructure means that I will be able to design my frontend build process. It will ensure that this build process, using Webpack, is optimised for these containerised environments, ensuring smaller image layers and faster boot times.

Ayodeji: Accessibility is an engineering discipline, not a design requirement. I treat WCAG Standards like any other syntax error. Technically, we enforce this through static analysis and automation. First, we utilise ESLint plugins like jsx-a11y to perform basic error linting – missing aria-labels or bad contrast during the coding phase. We then use Playwright for running automated accessibility audits (injection of the axe-core engine) of our build pipeline, ensuring we are semantically correct, using proper HTML5 landmarks and ARIA states before the code ever reaches production. It is a central part of the “rigorous testing strategy” I set up at Reusers.

Ayodeji: I just finished a course on product management because the future, to me, belongs to engineers who know about the business case. I am not just aiming to be a “coder”; I want to be a product architect. Be it setting up CI/CD pipelines using GitHub, whether it’s Actions and AWS or optimising SEO, I find myself asking, “How does this solve the user’s problem?” The objective is still the same: to develop digital experiences that are robust, more available, and more pleasant. The technology is changing, but the mission of serving the user stays the same.