DEV Community: Oge Obubu

What Being a Hands-On CTO Is Teaching Me About Leadership

Oge Obubu — Fri, 19 Jun 2026 10:43:55 +0000

When I became a CTO, I knew the role would involve making technical decisions, shaping product direction, and thinking about scalability.

What I did not fully appreciate was how often leadership would require me to move between the big picture and the smallest implementation details.

One moment, I am thinking about architecture, business priorities, and the future of Foodmartex. Next, I am sitting with our frontend developer, tracing an API response, investigating a broken user flow, or figuring out why the interface is not behaving as expected.

That contrast has become one of the most rewarding parts of the role.

Leadership Is More Than Giving Instructions

It is easy to imagine technical leadership as having all the answers and telling people what to do.

My experience has been different.

Sometimes leadership means providing direction. Sometimes it means asking the right questions. Other times, it means getting close to the problem and working through it with the person responsible for solving it.

Helping our frontend developer has taught me that my job is not to take over whenever something becomes difficult. My responsibility is to provide enough clarity and support for the developer to move forward confidently.

The goal is not dependence. The goal is growth.

The Frontend Reveals the Truth

A backend feature can look complete until someone tries to use it through the interface.

That is where hidden problems begin to appear: inconsistent API responses, unclear status transitions, missing validation, confusing user journeys, and assumptions that seemed reasonable during development but do not work in practice.

Working closely with the frontend has helped me see our product through the eyes of the people who will eventually use it.

It has also reminded me that the frontend and backend are not separate products. They are two parts of the same experience. If they do not communicate properly, the user does not care which side caused the problem. They only know that the product is not working.

Knowing When to Step Back

Being hands-on comes with its own challenge.

When you have the experience to solve a problem quickly, it can be tempting to jump in and do everything yourself. But constantly taking over may fix today’s issue while preventing someone else from developing the confidence to solve tomorrow’s.

I am learning to pause before stepping in.

Does the developer need an answer, more context, or simply the space to investigate?

Good technical leadership requires knowing when to lead from the front, when to work beside your team, and when to get out of their way.

I Am Growing Too

The work we are doing on Foodmartex is still a journey. We are building, testing, correcting assumptions, and strengthening the foundation behind the product.

But the product is not the only thing being developed.

This experience is also shaping me into a better leader: one who listens more carefully, communicates more clearly, and understands that leadership is not about appearing distant from the work.

It is about being close enough to understand the challenges, experienced enough to provide direction, and disciplined enough to let other people grow.

I am still learning.

I am still building.

And that may be the most honest description of leadership I can give.

Building Backend Systems That Hold Up Beyond the Happy Path

Oge Obubu — Fri, 19 Jun 2026 05:55:27 +0000

This week, my work as a backend engineer was focused on one thing: making real business flows behave like real business operations.

A lot of backend work is invisible when it is done well. Users do not see the state transitions, the rider matching rules, the settlement timing, the validation layers, or the historical checks behind a clean API response. But those details are what make a platform reliable.

At the start of the week, I worked through customer-to-rider order flow tracing, mapping how requests move across customer, vendor, rider, and admin surfaces. That kind of work matters because it prevents teams from building on assumptions. Before changing a flow, you need to know who owns each action, which endpoint is canonical, and where the handoff really happens.

A major part of my week went into strengthening the laundry service flow. Laundry is not a simple one-leg delivery like food. It has pickup, vendor receipt, processing, readiness, return dispatch, delivery, and settlement. I worked on making that lifecycle more professional by improving rider matching, pickup and return handling, status transitions, delivery fee/service charge calculations, cancellation reasons, and rider settlement fields.

I also worked on reward and onboarding logic, especially around welcome rewards and customer state. One important backend lesson from this: current profile data does not always tell the full historical story. A customer may have completed onboarding, received a reward, and later changed or removed address data. Good backend logic has to separate live relationship state from historical eligibility state.

Some highlights from this week:

Improved laundry rider matching and two-leg order handling
Added settlement support for laundry pickup and return flows
Enhanced laundry cart summaries with service charges and total calculations
Added express and insurance options for laundry services
Improved cancellation handling across laundry, market, and parcel orders
Enhanced rider parcel delivery filtering and history queries
Improved rider ongoing order details with current rider information
Traced customer-to-rider route surfaces to clarify real API contracts
Debugged onboarding and welcome reward behavior using historical state, not just current payload fields

Backend engineering is not just writing endpoints. It is designing trust into the system.

The best backend work answers questions before they become production issues:

Can this flow recover from partial progress?
Does the next actor know what to do?
Can finance settle correctly?
Can support understand what happened?
Can the frontend trust the response?
Can the business scale this without manual explanation?

That was the theme of my week: turning complex operational workflows into backend systems that are clearer, safer, and more reliable.

Connect with me:
GitHub-> @ogeobubu
X -> @ogeobubu
Instagram -> @ogeobubu

Building Better Product Experiences Through Quiet Improvements

Oge Obubu — Wed, 17 Jun 2026 05:22:46 +0000

Yesterday was focused on the kind of product work that often happens behind the scenes but directly affects the quality of the user experience.

The team worked on improving access to promotional experiences within the platform, making it easier for users to discover offers and value-driven moments. Work like this may seem small, but navigation and discoverability are important parts of how people experience a product.

There was also cleanup done within the frontend codebase. Removing unnecessary complexity helps keep the platform leaner and easier to maintain. It also gives the team more room to move faster when building future improvements.

Alongside that, a stability issue in the app setup was corrected. These kinds of fixes are important because they protect the user experience from avoidable friction.

Not every product update needs to be loud. Some of the most important progress happens in the details: cleaner structure, better access, fewer rough edges, and a stronger foundation for what comes next.

The Day We Fixed Our Signup Pipeline

Oge Obubu — Tue, 16 Jun 2026 04:23:48 +0000

It started with a graph.

Our signup numbers were climbing every week. The team was excited—growth was happening. But something felt off. A lot of those "users" never came back. Their email addresses looked strange. And our activation rate was quietly dropping.

One Friday afternoon, I decided to dig into the data.

What I found was not growth. It was noise.

The Diagnosis

I ran a simple query: group signups by IP address, count them, and sort descending.

The top result: one IP address had registered hundreds of accounts in the past 24 hours.

Same browser fingerprint. Same pattern. A script, probably hitting our register endpoint, generating accounts with throwaway email domains, and moving on.

I checked the user agents. Tools, not people.

I checked the email domains. Addresses that expire before the welcome email is even sent.

Our signup pipeline was wide open. Anyone, or anything, could walk in.

The Approach

We needed protection in layers. Not a single gate, but a series of filters. Each one catches something the others might miss.

We decided on three layers. And we built them all in a single sprint.

Layer 1: Throttling

The most obvious fix: rate limiting. But not just one limit, two.

Per-IP throttling: A small number of signup attempts per IP address within a short window. If you hit the limit, you get a clear response telling you when to retry.

No ambiguity.

Per-domain throttling: An even smaller tolerance for signups from the same email domain within a longer window. This catches distributed attacks, a bot using different IPs but always the same throwaway domain.

Two counters. A bot that shares either an IP or a domain gets stopped.

Layer 2: Blocklists

Rate limiting slows things down, but it doesn't stop determined attackers. They'll wait and come back. We needed permanent blocks.

Blocked email domains: We maintain a list of disposable email domains. Any registration attempt using one gets rejected before the data touches the database.

Blocked user agents: If the request comes from a non-browser tool, it's rejected with a simple error. No explanation. No details. Attackers don't need to know why they were blocked.

Layer 3: IP Blocklist

Some IPs are persistent. They've been flagged before. They've abused other endpoints, not just signup. Rate limiting won't stop them. Blocking their user agent won't stop them if they switch.

We needed a hard blocklist, IPs that are rejected for every request, not just registration.

The message is deliberately terse. No explanation. No recourse. The middleware runs on every route, every method, every request. If your IP is on the list, you don't get through.

Before and After

Before:

Hundreds of accounts from a single IP in 24 hours
Throwaway email domains made up a significant percentage of new signups
Activation rate was diluted by fake accounts
Every data-driven decision was slightly wrong because the denominator was inflated

After:

Same-IP registration farming dropped to zero
Disposable domain signups disappeared
Our signup numbers reflected actual human intent
Activation rate recovered, because the denominator now represented real users

What We Learned

1. Signal matters more than volume.

When signups are inflated by bots, every metric that depends on user count becomes unreliable. Activation rate. Retention. Revenue per user. Cleaning the pipeline made every downstream number trustworthy again.

2. A small amount of code can fix a big problem.

The solution wasn't complex. It was layered. Three simple mechanisms, each handling what the others miss.

3. Layers matter.

A single rate limit would have slowed the bots but not stopped them. A single blocklist would have caught the obvious ones but missed the persistent ones. The combination covers more surface area than any one approach.

4. Not all rejections are equal.

We chose our responses carefully. Legitimate users get useful feedback. Bad actors get silence. The message you send reveals how much information you want the requester to have.

The Takeaway

A healthy signup pipeline doesn't make the news. Nobody sends a tweet saying "I tried to sign up and couldn't because the IP throttling worked correctly."

But the absence of this work would eventually make headlines, just not the kind you want.

Growth is not just about getting users in the door. It's about making sure the users who come through are real. Every decision you make, product direction, marketing spend, feature priorities, depends on the quality of your data. And your data quality starts at the first line of defense: the registration endpoint.

The bots stopped. The data cleaned up. And our growth metrics finally told the truth.

The Parcel That Taught Me Everything

Oge Obubu — Fri, 12 Jun 2026 01:35:28 +0000

Two months ago, my product manager walked up to my desk and said four words: "We need parcel delivery." I nodded confidently. Inside? I had no clue where to start. FoodMartex was already handling food orders—customers ordering from restaurants, riders delivering meals, and admins managing operations. Adding parcel delivery meant building a second nervous system alongside the first one. Same platform. Same users. Entirely new logic. I said yes anyway. Sometimes that's all you need to do.

The False Start

Week one was humbling. I opened my editor and stared at the blank screen for what felt like hours. Where do you even begin with something this big? I started with the customer create page—a form with pickup and dropoff locations, item type, weight, and dimensions. Google Places autocomplete, real-time cost estimation, field validation. It was supposed to be the "easy part." It wasn't. The first version was a mess. The autocomplete broke when users typed too fast. The cost estimator fired at the wrong time. Validation errors showed up in the wrong places. I deleted the whole thing and started over. Then I did it again. The third time, I stopped trying to write perfect code and just wrote working code. That was the moment everything changed.

The Map That Broke Me

Week three. The rider interface. Riders needed an interactive map that showed pickup location, drop-off location, and their own live position. A route line connecting all three. Stage tracking—are you heading to pick up your parcel, or are you on your way to deliver it? I remember Friday night. I was trying to draw a simple line between two points using Leaflet. A basic polyline. Should have taken five minutes. Three hours later, I was still staring at a blank map. I went to bed frustrated. I woke up Saturday and tried again. Nothing. Saturday night, I almost gave up and used a static map instead. Sunday, 2 a.m. I don't know what changed. Maybe my brain finally processed the problem. But the line appeared. A green route from point A to point B. I took a screenshot. Sent it to no one. Just sat there and smiled.

The Tracking That Wouldn't Quit

By week five, the pieces were coming together. But real-time tracking was the thing that scared me most. Every ten seconds, the tracking page polls the server for the latest status. Sounds simple. But what happens when:

Is the network slow?
The user refreshes mid-poll?
The status changes between two polls?

The rider loses GPS signal? I handled each case one at a time. The status badges changed colour—green for delivered, red for cancelled, blue for in transit, and orange for pending. Small details, but they told a story. The first time I saw a status transition from "pending" to "in transit" to "delivered" in real-time on my screen, I refreshed the page three times just to make sure it wasn't a fluke. It wasn't.

The Final Stretch

Weeks six through eight were about tying everything together. An admin panel with rider assignment, pricing configuration, and a full timeline. A rider history page with filters. A customer list with cancel capability. The patterns were clear by now. The hard lessons from weeks one through five had become muscle memory. I was no longer fighting the code — I was simply writing it. Three days ago, a real user opened the app. Created a parcel delivery. A rider accepted it on the map. Picked it up. Dropped it off. The tracking updated every ten seconds from start to finish. I didn't do anything special. I just watched.

What I Learned: Two months ago, parcel delivery was a blank Vite project. Today it's 11 pages across 3 user roles, 3 API services, an interactive map, and real-time tracking that actually works. But the real lesson isn't technical. It's this: You don't need to know how to build something before you start building it. You just need to be willing to write bad code first, learn from it, and rewrite it better the next time. The map didn't work on Friday. It worked on Sunday at 2 a.m. Between those two points, nothing changed except I didn't give up. That's the whole secret. There's nothing else.

Efficient Pagination in React: Best Practices for API Calls

Oge Obubu — Sat, 14 Sep 2024 09:53:48 +0000

Introduction

Pagination is a common feature in web applications. It allows users to navigate large datasets without being overwhelmed by information, however, if this is not done properly pagination can lead to performance issues and a frustrating user experience. In this post, we'll explore best practices for managing pagination in React applications, especially when they're interactive with backend API.

Understanding Pagination

When dealing with large data sets it is important to divide information into parts that can be managed. Pagination allows users to view a subset of items at a time. This makes navigation easier and more intuitive. However, continuously fetching data from the server every time the user clicks to navigate can cause unnecessary stress on both the client and server.

Why Avoid Continuous API Calls?

Performance concerns: Frequent API calls can slow down your application. As a result, users must wait longer.
Server load: Too many requests can overwhelm the server. This results in reduced performance or even crashing.
User Experience: Loading and unloading data quickly can create a jarring experience for users.

Best Practices for Efficient Pagination

Debounce API Calls
Using the debounce mechanism can help limit the frequency of API calls. This technique delays the execution of API requests until the user has paused interacting with the pagination control.
Local Caching
Caching previously retrieved data helps to display items quickly without additional API calls by storing the results locally. You can give users immediate feedback when they return to previously viewed pages.
Prefetching data
Try prefetching data for adjacent pages. When the user is on page N, you can load data from pages N+1 and N-1 in the background. So when they click "Next" or "Previous" the information is already there. This results in a smoother experience.
Loading indicator
Always provide feedback to users when retrieving data. Loading the spinner or message will inform the user that their action is being performed. This will help improve the overall experience.

Implementing Efficient Pagination in React

Here's a simple example of how to effectively use page scheduling in React applications:

import React, { useState, useEffect } from 'react';

const PaginatedList = () => {
  const [items, setItems] = useState([]);
  const [page, setPage] = useState(1);
  const [totalPages, setTotalPages] = useState(0);
  const [cache, setCache] = useState({});

  async function fetchItems(page) {
    if (cache[page]) {
      setItems(cache[page]);
      return;
    }

    const response = await fetch(`/api/items?page=${page}&limit=10`);
    const data = await response.json();
    setCache(prev => ({ ...prev, [page]: data.items }));
    setItems(data.items);
    setTotalPages(data.totalPages);
  };

  useEffect(() => {
    fetchItems(page);
  }, [page]);

  function handleNext() {
    if (page < totalPages) {
      setPage(page + 1);
    }
  };

  function handlePrevious() {
    if (page > 1) {
      setPage(page - 1);
    }
  };

  return (
    <>
      <ul>
        {items.map(item => (
          <li key={item.id}>{item.name}</li>
        ))}
      </ul>
      <div>
        <button onClick={handlePrevious} disabled={page === 1}>Previous</button>
        <span> Page {page} of {totalPages} </span>
        <button onClick={handleNext} disabled={page === totalPages}>Next</button>
      </div>
    </>
  );
};

export default PaginatedList;

Code Description

State management: We manage the current page. Total number of pages and archiving of previously retrieved items.
Fetching data: The fetchItems function checks if the requested page is cached. If so, we will use accumulated data, otherwise, an API call will be made.
Pagination controls: Simple navigation buttons allow users to move between pages, with checks to prevent navigating beyond the existing page.

Conclusion

Using effective page scheduling in your React application not only increases performance but also improves performance. But it also greatly improves the user experience. By avoiding unnecessary API calls through techniques such as caching and prefetching. You can create a smooth interface that attracts users.

By following these best practices You can be sure that your pagination isn't just functional. But it's also powerful and easy to use. Happy coding!

Maximizing Efficiency: Proven Strategies for Boosting Productivity

Oge Obubu — Fri, 27 Jan 2023 05:47:12 +0000

Productivity is a topic that is important to many people, as it can have a significant impact on our ability to achieve our goals and accomplish our tasks. Whether you are a student, an employee, or a business owner, there are many strategies and techniques that you can use to increase your productivity and make the most of your time.

One of the most important things to consider when trying to improve your productivity is to set clear, specific goals for yourself. This will give you a sense of direction and help you stay focused on what you need to do. It is also important to break down your goals into smaller, more manageable tasks, as this will make it easier to make progress and stay on track.

Another key aspect of productivity is time management. This involves being able to effectively use your time to accomplish your tasks, rather than wasting it on unimportant or unnecessary activities. One of the most popular time management techniques is the Pomodoro Technique, which involves breaking your work into 25-minute intervals, with short breaks in between. This can help you stay focused and avoid burnout.

Another important aspect of productivity is organization. This includes things like keeping your work area clean and tidy, having a clear filing system, and using tools like calendars and to-do lists to keep track of your tasks. Being organized can help you stay on top of your tasks and avoid feeling overwhelmed by the amount of work you have to do.

There are also a number of tools and technologies available to help you increase your productivity. For example, apps like Evernote and Trello can help you stay organized and on top of your tasks, while tools like RescueTime can help you track how you are spending your time and identify areas where you might be wasting time.

One strategy that can boost productivity is to learn to prioritize. This means that you focus on the most important tasks first, and then work on the less important tasks later. By focusing on the most important tasks, you will be able to make the most progress and accomplish the most in a given period of time.

Another strategy is to take breaks, it is important to take breaks regularly to refresh your mind, so that you can stay focused and productive. Breaks can be as simple as going for a walk, or even just stepping away from your desk for a few minutes.

In addition to these strategies, there are also a number of other things you can do to improve your productivity. For example, getting enough sleep, eating a healthy diet, and exercising regularly can all have a positive impact on your productivity.

In conclusion, productivity is an essential aspect of achieving our goals and getting things done. By setting clear, specific goals, practicing time management, staying organized, and using tools and technologies to help you, you can increase your productivity and make the most of your time. Remember to also prioritize, take breaks, and maintain a healthy lifestyle for an overall boost in productivity.

From zero to hero: A beginner's guide to frontend development

Oge Obubu — Tue, 24 Jan 2023 09:43:05 +0000

Frontend development is the practice of converting data into a user-friendly interface. It is the process of creating the visual and interactive elements of a website or application that users interact with.

If you're new to frontend development, it can be overwhelming to know where to start. But with the right resources and guidance, you can go from a beginner to a skilled frontend developer in no time.

The first step in frontend development is understanding the basics of HTML, CSS, and JavaScript. HTML (Hypertext Markup Language) is used to create the structure of a website, CSS (Cascading Style Sheets) is used to control the visual layout and design, and JavaScript is used to create interactive elements and dynamic functionality.

Once you have a solid understanding of these three languages, you can start experimenting with frameworks and libraries such as React, Angular, and Vue.js. These tools provide pre-built functionality that can save you time and help you create more complex and powerful websites.

It's also important to understand responsive design, which is the process of creating a website that adjusts to fit the screen size of the device it's being viewed on. With more and more users accessing the web on mobile devices, it's essential that your website is easily accessible and usable on all devices.

Web Accessibility is another important aspect of frontend development. As a frontend developer, it's your responsibility to ensure that your website is accessible to all users, including those with disabilities. This can include providing alternative text for images, using semantic HTML, and providing keyboard navigation.

In addition to these core skills, it's important to stay up-to-date with the latest trends and technologies in frontend development. This includes learning about Progressive Web Applications (PWA), web assembly, and the use of AI and Machine Learning in web development.

As you gain experience and build your skills, don't be afraid to experiment and try new things. The beauty of frontend development is that there are always new tools and techniques to learn and new problems to solve. With determination and a willingness to learn, you can go from zero to hero in the world of frontend development.

In conclusion, frontend development is an essential part of web development, and a vital skill in today's digital world. With the right resources and guidance, anyone can learn frontend development, and with time and practice, you can become an expert in the field. Remember, the most important thing is to start somewhere, and to never stop learning.

What's So Trendy About Web3.0 That Everyone Went Crazy Over It?

Oge Obubu — Sun, 09 Jan 2022 08:56:56 +0000

You have probably seen the term “ web 3.0 ” drifting on the internet. Simply put, web 3.0 is the new form of the web’s process. These changes that web 3.0 is taking to the net is starting to make it to a whole new level. Expert scientists and web experts think that these modifications are starting to make the web smarter and our lives easier. Therefore, to see these paradigm-shifting changes, get’s first see the development of the internet as we learn it.

Presently, to the best of my learning, there is no pragmatic explanation for web 3.0 yet and the technology that can make us there has not yet grown yet. Then to get a better familiarity with web 3.0, let us see the example. In web 2.0, users will interact with sites that have predetermined behaviours according to the information of users. Users will search for data using different search engines which generally give acceptable results if there is sufficient data regarding the search. Still, this search is just for keywords and takes in the most common information available, and does not comprehend the context of this quest. So if the person searches for an insect named the Camaro and uses just that one language, So almost 90% of the search outcomes exist for the Chevy Camaro model of auto and not the insect because the automobile is the most common search outcome and gets the most prolific information. Simply put, Web 2.0 is built around the user, producer to build a way to enable and engage them. Though whatever has an advantage will surely have a disadvantage, Web 2.0 has a few drawbacks and they are:

Lack of control.
Lack of privacy.

Lucky enough Web 3.0 nullifies these disadvantages. Here are a few of the advantages of Web 3.0:

Privacy.
Data Ownership & Sharing.

Berners-Lee's conception of the Semantic system is in obvious contrast to the advocates of web 2.0, which he gets strongly criticised. This Semantic system may more properly be referred to as one process of web 3.0, which includes more improvements in this “ back-end ” information structure, particularly information tags, to support natural language searches and data mining. (Britannica .)

Web 3.0 will be a total reinvention of the web, something that Web 2.0 was not. Web 2.0 was simply an expansion from the original Web which can be compared to a library, as Web 1.0 was essentially an info dump, a place where people just positioned walls upon walls of text which people can read but usually not interact with. Web 2.0 revised this by allowing user interaction with dynamic websites that acted more like applications than simply pages of information.

Does any of this interest you? I sure hope so.

Do well to follow me on:

Thank you for reading🎊

JavaScript Function Composition: What is Composition Function?

Oge Obubu — Mon, 03 Jan 2022 04:32:31 +0000

Function Composition:

Just like real function in Mathematics that looks like f(x) so also this is found in programming languages like JavaScript.

JavaScript according to Wikipedia is a programming language that is one of the core technologies of the World Wide Web, alongside HTML and CSS. Over 97% of websites use JavaScript on the client-side for web page behaviour, often incorporating third-party libraries.

Function Composition is the combination of several functions into a smaller function. It is also an approach where the result of one function is passed on to the next function, which is passed to another until the final function is executed for the final result. Function compositions can be composed of any number of functions. Or better still, the composition function takes any number of functions and invokes them all one after the other.

function add (a, b) {
  return a + b;
}

add(2, 3)

// output: 5

The above code snippet is a simple form to write a function in JavaScript. That being done,
let's create several functions to the very end we have a smaller function in order to achieve function composition.

var addTwo = (a) => {
 return a + 2;
}

var addThree = (b) => {
 return b + 3;
}

addTwo(addThree(2))

// output: 7

addTwo function takes a value of a while addThree is a function that takes a value of b. Composing the two functions together JavaScript performs firstly the statement of a function that is inside another function i.e addThree function, the statement is b (which is 2 in this case), return 2 + 3 which results in 5.

Now, we have addTwo(5) since the addThree function has been performed.

addTwo(5) performs the function by adding two (2) to 5 which gives 7 hence our result.

Importance of Composition Function

There is importance to the usage of composition function which is the reusability of functionality at a very high level.

Libraries for function composition

Lodash: One of the most popular libraries used by developers today. It is a JavaScript library that provides utility functions for common programming tasks using the functional programming paradigm.
Ramda: A practical functional library for JavaScript programmers.

These libraries can be used to avoid implementing either function so you can focus on its uses of it.