DEV Community: Oge Obubu

Stop Using `useEffect` for Data Fetching—Please, I Beg You

Oge Obubu — Sun, 26 Jul 2026 15:55:42 +0000

The Scene

It's 2 AM. You're staring at your screen, debugging why your dashboard keeps showing yesterday's data even after you've changed the filter. Your useEffect dependency array looks like a crime scene. You've got three useState hooks just to manage loading, error, and data. You added a cleanup function, but somehow the component still throws that dreaded warning: "Can't perform a React state update on an unmounted component."

You take a sip of cold coffee. You wonder where it all went wrong.

The Problem with `useEffect` for Data Fetching

Let's be honest with ourselves. useEffect was never designed for data fetching. The React team gave us this hook to synchronize with external systems, DOM events, subscriptions, and timers. But somewhere along the line, we collectively decided to use it as our go-to tool for API calls.

And look, I get it. When you're learning React, the pattern is simple:

useEffect(() => {
  const fetchData = async () => {
    setLoading(true);
    const response = await fetch('/api/users');
    const data = await response.json();
    setUsers(data);
    setLoading(false);
  };
  fetchData();
}, []);

It works. Until it doesn't.

Here's what happens when your application grows:

Race Conditions — When your user clicks filters too quickly, old requests return after newer ones and override your state. The UI shows mismatched data, and you waste hours adding request cancellation logic that nobody on your team fully understands.

Unnecessary Re-renders — Every state update triggers a re-render. With useEffect, you're juggling at least three states: data, loading, and error. Three states, three renders, even before React mounts your actual content.

Poor Caching — If a user visits a page, leaves, and comes back, your useEffect fires again. Same data, same API call, same network cost. Multiply this by a thousand users, and you're burning your backend for no good reason.

Manual Cleanup Headaches — Need to cancel pending requests? Need to prevent state updates after unmount? You'll write boilerplate that distracts from your actual business logic.

Enter TanStack Query (Formerly React Query)

Now, imagine a different approach. Instead of telling React how to fetch data, you simply tell it what data you need:

const { data, isLoading, error } = useQuery({
  queryKey: ['users', filter],
  queryFn: () => fetchUsers(filter),
});

That's it. No useState. No useEffect. No cleanup. Just a declarative statement: "Give me users based on this filter, and handle all the complexity for me."

What TanStack Query Gives You That `useEffect` Never Will

Automatic Caching — When a user navigates away and returns, the data is already there. No additional network requests. Your application feels fast because it is fast.

Deduplication — If two components request the same data simultaneously, TanStack Query makes a single request and shares the response. Your backend thanks you.

Background Refetching — Stale data automatically updates in the background. Your users always see fresh information without spinners interrupting their flow.

Retry Logic — Network failure? Server error? TanStack Query retries intelligently with exponential backoff. You don't have to write that logic yourself.

Optimistic Updates — When a user submits a form, you can update the UI immediately and sync with the server in the background. The experience feels instant.

Devtools — A Chrome extension that shows you exactly what's cached, what's fetching, and what's stale. No more guessing why data isn't showing.

The Real Difference

Here's the thing: when you use useEffect, you're managing imperative side effects. You're telling React: "When this component renders, do this thing, then clean up when it unmounts."

When you use TanStack Query, you're managing declarative state. You're telling React: "I need this data. Handle the rest."

One approach makes you a plumber, constantly fixing leaks. The other makes you an architect, designing systems that work.

A Practical Example

Consider a dashboard with filters, pagination, and auto-refresh. With useEffect, your code grows into a tangled mess of dependencies:

useEffect(() => {
  let isMounted = true;
  const controller = new AbortController();

  const fetchData = async () => {
    setLoading(true);
    try {
      const response = await fetch(
        `/api/sales?page=${page}&filter=${filter}`,
        { signal: controller.signal }
      );
      const data = await response.json();
      if (isMounted) setSales(data);
    } catch (error) {
      if (isMounted && error.name !== 'AbortError') {
        setError(error);
      }
    } finally {
      if (isMounted) setLoading(false);
    }
  };

  fetchData();

  const interval = setInterval(fetchData, 5000);

  return () => {
    isMounted = false;
    controller.abort();
    clearInterval(interval);
  };
}, [page, filter]);

Look at that. Twenty lines of boilerplate just to fetch data with cleanup, cancellation, and polling.

Now the TanStack Query version:

const { data, isLoading, error } = useQuery({
  queryKey: ['sales', page, filter],
  queryFn: () => fetchSales(page, filter),
  refetchInterval: 5000,
});

Eight lines. Clean. Readable. Maintainable.

But Wait—Is `useEffect` Completely Obsolete?

No. Let's not throw the baby out with the bathwater.

useEffect still has valid use cases:

Synchronising with non-React systems — Integrating with third-party libraries like Google Maps, Chart.js, or Stripe elements.
Adding event listeners — Window resize, scroll position, keyboard shortcuts.
Managing animations — Triggering transitions when props change.
Logging analytics — Tracking page views and user interactions.

The key distinction is this: useEffect is for synchronisation, not data fetching. If your effect reaches out to a server, you're probably using the wrong tool.

What You Gain by Making the Switch

Faster Development — Less boilerplate means more time building features that matter to your users.

Fewer Bugs — Race conditions, memory leaks, and stale data become problems of the past.

Better User Experience — Instant navigation, background updates, and optimistic mutations make your app feel native.

Reduced Server Load — Intelligent caching cuts your API calls by 60–80%.

Easier Onboarding — New developers grasp the data flow in minutes rather than days.

A Word for the Sceptics

I know what some of you are thinking: "Another library? I'm tired of learning new things."

But here's the truth—this isn't just a library. It's a paradigm shift. It's acknowledging that we've been doing data fetching the hard way for too long.

TanStack Query has been battle-tested in production for years. It powers applications at companies you know and respect. It's not going anywhere.

And once you learn it, you'll wonder how you ever lived without it.

The Bottom Line

Your useEffect code isn't working. It's working enough, which is different.

You've been surviving, not thriving.

You've been fixing bugs that shouldn't exist.

You've been writing code that future you will curse.

Stop making your life difficult. Stop making your users suffer. Stop making your backend engineers cry.

The tools exist. The knowledge is available. The only thing standing in your way is inertia.

Your Next Step

Tomorrow, open your codebase. Find a single useEffect that fetches data. Replace it with useQuery.

Time it. See how long it takes.

Then ask yourself: why didn't I do this sooner?

Because once you taste the difference, you'll never go back.

Your API is tired. Your users are waiting. Your team deserves better.

Make the switch today.

We Built a Super-App in 30 Days. Here's the Chaos Nobody Saw.

Oge Obubu — Wed, 15 Jul 2026 19:49:02 +0000

One team. Thirty days. Nine service verticals. Fifty-plus screens. And one question that kept us up at 5 AM: "Can this actually work?"

Day 1: "It's Just a Food App… Right?"

Picture this.

It's June 1st. We're staring at a food delivery app. It works. Customers can order jollof rice from restaurants nearby. Life is good.

Then someone says the words that changed everything:

"What if users could also order from pharmacies? Supermarkets? Local markets? What if they could send parcels? Do laundry? Plan events for 500 guests?"

We laughed.

Then we opened the codebase.

And for the next 30 days, we didn't sleep.

Week 1: The Multi-Service Monster Awakens

Here's what nobody tells you about building a super-app: it's not one app. It's nine apps wearing the same jacket.

Monday — We started with pharmacy. Simple, right? Browse pharmacies. Search medications. Add to cart. Checkout.

Except "simple" turned into service-specific checkout flows, quantity-based ordering, and a whole new category discovery system pulled live from vendor inventory.

**Tuesday—Supermarket hit the codebase. Grocery products. Category tabs. Search that actually returns what you're looking for. Another service. Another checkout flow. Another 2,000 lines.

Wednesday — Local Market. Think open-air Nigerian markets — but on your phone. Vendors. Items. Real-time availability. The same pattern, but different enough to need its own identity.

Thursday — Laundry. Pickup addresses. Express service options. Insurance support. Because what's a super app without someone washing your clothes?

Friday — We stepped back and looked at the home screen. It had become a cluttered mess of cards and banners. So we rebuilt it. A clean 3-column grid. Service-specific accent colors—teal for pharmacy, blue for laundry, green for local market, and yellow for supermarket. Each section pulling its own featured vendors from the backend.

By Friday night, the app had gone from one service to five. The home screen looked like it belonged in a design portfolio, not a sprint review.

The codebase had grown by 8,020 insertions across 40 files in the first week alone.

But we weren't done. Not even close.

Week 2: The Features That Made People Say "Wait, This App Does THAT?"

The Meal Subscription Engine

Picture a busy professional in Ile-Ife. Every morning, they stare at their phones, wondering, "What am I going to eat today?"

Now imagine they could subscribe to a meal plan—breakfast, lunch, and dinner—for an entire month. Pick their vendor. Set their delivery times. Let the app handle the rest.

We built a calendar-based subscription system with a scrollable view, in-place editing of delivery times and addresses, pause and cancel functionality, auto-renewal toggles, and a real-time cost preview that updates as you configure your plan.

The calendar alone took three days. The backend integration took another two. The UX debates? Those are still ongoing.

Corporate Meal Plans (Staff Lunch)

Then the sales team dropped a bomb:

"What if companies could manage staff lunches through the app?"

Staff count. Meal budget per person. Delivery schedule across workdays. Delivery time windows.

We built a full corporate meal program—because apparently, the app that started with jollof rice is now running companies' lunch breaks.

Global Search That Actually Finds Things

You know those search bars that show you the same three results no matter what you type? Yeah, we didn't want that.

We built a unified global search with a scoring algorithm. Type "paracetamol," and it finds the pharmacy vendor, the specific medication, AND deep-links you to the right screen. Type "pizza" and you get restaurants, specific menu items, and even your past orders.

Fifty-plus screens. All searchable. All from one floating button in the tab bar.

Week 3: Gamification, Predictions, and the Spin Wheel That Broke Our Brains

The Spin Wheel

Everyone loves a good spin wheel. Ours has animated graphics with multi-rotation physics, eligibility checks, daily limits, live expiry countdowns on rewards, and a dedicated inventory screen where users track their claimed, pending, and expired rewards.

The animation alone required custom interpolation math. But when that wheel spins and the user wins? Worth every broken keyboard shortcut.

FIFA 2026 World Cup Predictions

This one was pure chaos — the good kind.

We built an in-app prediction system where customers pick match winners for the 2026 World Cup. View fixtures. Submit predictions. Track your prediction history. Climb the leaderboard.

There's a leaderboard that filters by week and month. Trophy icons. Gold badges. The works.

It turned a delivery app into a social experience. People aren't just ordering food anymore. They're arguing about whether Brazil beats Germany.

Week 4: Payments, Parcels, and the Stuff That Actually Matters

Here's the unglamorous truth: the flashiest features mean nothing if payments fail.

Seamless In-App Payments

Before this month, payments opened in an external browser. Users would get redirected, lose context, and sometimes never come back.

We moved payments into an in-app experience. Seamless. In-context. No browser switches.

But that was just the beginning:

Payment retry for failed orders — because networks are unreliable and users shouldn't have to start over
Duplicate submission protection—no more double-charging because someone tapped "Pay" twice
Background transaction verification — the app checks payment status even when the user isn't looking

Parcel Delivery, Done Right

Send a parcel from Ile-Ife to Abuja. Enter sender and recipient details. Pick a pickup address. Choose a drop-off. Schedule the delivery. Get a delivery code. Track the parcel in real time.

We built autocomplete for addresses using Google Places. Time pickers for scheduling. Reverse geocoding for manual address entries. A timeline tracker that shows every step from pickup to delivery.

It's not just sending a package. It's watching it travel across the country.

Live Delivery Tracking

Speaking of maps—we went deep on Google Maps integration:

Real-time rider markers moving across the screen
Route directions with distance and ETA
Automatic map framing
Rider profile display with a call button

The delivery map is the screen users stare at the most. We made sure it's beautiful, reliable, and informative.

The Invisible Architecture Nobody Talks About

Guest-to-Authenticated Cart Merging

A user opens the app without logging in. Browses pharmacies. Adds paracetamol to their cart. Then signs in.

The paracetamol is still there. Seamlessly merged. No data loss. No duplicate cart entries.

Behind the scenes, a guest token system ensures every item makes the transition from anonymous browsing to a full account.

Network Resilience

Every API call has automatic retries with exponential backoff. The app doesn't crash when the network flickers. It waits, retries, and recovers.

Because in Nigeria, a network isn't a guarantee. We built for that reality.

The Numbers

Let's talk scale:

Metric	Count
Service Verticals	9
Screens	50+
Lines Inserted (This Month)	8,020+
Files Modified	40+
Gamification Features	3

What's Next?

We're not slowing down.

The "Coming Soon" slide in the onboarding screen isn't decoration—it's a promise. More services. More features. More reasons to open the app instead of downloading another one.

Because the goal was never to build a food delivery app.

The goal was to build the last app you'll ever need for daily services.

And in 30 days, we got very, very close.

Foodmartex is available on Android. iOS is coming soon.

Built with React Native, Redux Toolkit, and an unreasonable amount of determination.

I Built a Super-App Backend in 2 Weeks. Here's What Nobody Tells You About the Chaos.

Oge Obubu — Sat, 11 Jul 2026 04:42:15 +0000

Day 1: "How hard can it be?"

I had 14 days. One Laravel backend. Five verticals.

Food delivery
Marketplace
Pharmacy
Laundry
Parcel delivery

"Just connect everything and ship," I told myself.

Narrator: It was not that simple.

The Number That Keeps Me Up at Night

By Day 14, I was staring at:

1,028 PHP files
236 database migrations
65 commits in the Git history

Sixty-five commits in fourteen days.

That's not a project. That's a hostage situation with git push.

The Commission Problem Nobody Warned You About

Here's the thing about building a multi-vendor platform: everybody wants their cut.

The vendor wants theirs. The rider wants theirs. The platform wants its cut. And somehow, all of this needs to calculate correctly, down to the kobo, across every single order type.

I spent 3 days building a commission engine that handles:

Vendor commission percentages
Platform commission splits
Rider delivery fees
Markup calculations (global AND vendor-specific)
Null handling for every edge case that breaks at 2 AM

"What happens when both markup types are null?"

Nobody tells you about this in tutorials. You find out at 2 AM when your test user places an order, and the whole system divides by zero.

Notifications: The Invisible Monster

You know what's harder than building an order system?

Telling people about it.

I built a notification system that sends:

Push notifications with images (because text-only is 2019)
Real-time status updates for every order state
Market order events: accepted, en route, delivered, cancelled
Pharmacy order matching alerts
Laundry dispute handling flows

Each notification has to be:

Instant
Contextual
Delivered across multiple channels
Actually useful (not spam)

I wrote 428 lines of notification logic in one week alone.

The Payment Resurrection

Users abandon carts. Payment gateways time out. Networks flicker.

So I built a payment resurrection system: when a payment fails, or times out, customers can reinitialise and try again without losing their order state.

// Market orders — recoverable
// Pharmacy orders — resumable
// Laundry orders — retryable

All recoverable. All resumable. All tested.

Because nobody's perfect. But your payment system should be.

Real-Time Order Tracking

Every order has a lifecycle:

Placed → Accepted → En Route → Delivered

But what happens when things go wrong?

Customer disputes a laundry item
Rider can't find the address
Vendor runs out of stock after confirming

I built status logs for every single state change. Every transition. Every timestamp. Every reason.

Not because the client asked for it.

Because debugging without logs is just guessing with confidence.

The Feature Toggle That Saved the Day

Not everything should be live on Day 1.

So I built an ensureFeatureAvailable method that gracefully handles feature unavailability. If a feature isn't ready, users get a clean response instead of a 500 Internal Server Error.

if (!$this->featureEnabled($feature)) {
    return response()->json([
        'message' => 'This feature is coming soon.',
    ], 403);
}

Small thing. Huge impact.

What I Learned in 14 Days

Migrations are forever. Make them idempotent or make them twice. I chose twice.
Edge cases aren't edge cases. They're just cases you haven't hit yet. I handled null values in markup calculations on Day 12. Should've been Day 1.
Notifications are a product. Not an afterthought. The way you notify users IS the user experience.
Commission math is a philosophical problem. It's not about the numbers. It's about who gets paid, when, and how you prove it.
1,028 files is not a flex. It's a cry for help. But the system works. Every route. Every controller. Every relationship. It all connects.
Logs are not optional. If you can't trace an order from placement to delivery, you're not building a system. You're building a house of cards.

The Numbers

Metric	Count
Days	`14`
Git commits	`65`
PHP files	`1,028`
Database migrations	`236`
Verticals shipped	`5`
Edge cases fixed at 2 AM	`7`
Cups of coffee	[redacted]

The Architecture

├── Market Orders
├── Pharmacy Orders
├── Laundry Orders
├── Restaurant Orders
├── Parcel Delivery
├── Payment Recovery
├── Admin Dashboard
├── Spin Campaigns
├── Promo Engine
└── Notification System

One backend. Five verticals. One codebase.

What's Next

The backend is live. The API is stable. The foundation is solid.

But this is just the beginning.

Building the infrastructure was the hard part.

Making it scale? That's the interesting part.

If you're building something similar and want to talk shop, or if you just want to feel better about your own deadline, hit me up.

P.S. — If anyone asks, yes, I did rewrite the same migration three times. No, I will not elaborate.

The 4 PM Rush: A Day Inside a Growing Food Tech Platform

Oge Obubu — Sun, 28 Jun 2026 21:13:58 +0000

What happens when thousands of people decide they're hungry at the exact same time?

The Quiet Before the Storm

10:00 PM. The numbers are gentle tonight. One hundred eighty-nine requests trickle in. Someone in Lagos is ordering late-night suya. A rider in Ibadan is wrapping up his last delivery. In Bangladesh, someone is just discovering us for the first time.

By 11:00 PM, things get quiet. Just 8 requests. The platform takes a breath.

2:00 AM. A mystery. 151 requests spike out of nowhere. We check the logs. Nothing unusual. Just a group of night owls ordering food, maybe shift workers, maybe students pulling an all-nighter. The beauty of a platform is we're always on, always ready.

7:00 AM. Good morning, Nigeria. Fifty-five requests. People waking up, checking their wallets, planning their day. The coffee hasn't even brewed yet, but the platform is already humming.

The Morning Rush

9:00 AM. 315 requests. The workday begins. Offices buzz with conversations about lunch plans. If someone searches "foodmat site" for the third time this week, they're getting closer to finding us. A corporate client logs in to set up their employee meal program for the first time.

By 10:00 AM, the traffic settles to 50 requests. A calm before the real storm.

11:00 AM. 173 requests. The hunger is building. People are making decisions about what to eat, where to order, and which vendor to choose. Our World Cup campaign notifications ping. Someone shares their referral code. The viral loop begins.

The Lunch Explosion

12:00 PM. 321 requests. It's happening. The platform comes alive.

1:00 PM. 339 requests. The peak is building. Our servers are handling it smoothly. This is where the magic happens when thousands of people decide they're hungry at the exact same time.

2:00 PM. 289 requests. Still going strong. Vendor dashboards refresh. Riders accept orders. Laundry bookings come in alongside food deliveries. If someone cancels an order with a reason, we take note. Every interaction teaches us something.

3:00 PM. 528 requests. The highest peak of the day. It's the post-lunch rush, the afternoon cravings. People are ordering snacks and planning their evening meals. Our cache hits 53%, serving data from memory instead of the origin. The platform is fast, responsive, and alive.

The Evening Surge

4:00 PM. 214 requests. A slight dip, but don't be fooled. Dinner planning begins.

5:00 PM. 254 requests. The commute starts. People are ordering before they leave work, so dinner arrives when they get home. A parent orders for the family. A young professional uses their corporate meal benefit for the first time.

6:00 PM. 392 requests. This is the golden hour. The dinner rush. Our cache hit rate jumps to 77%. The platform is serving data fast, efficiently, and reliably. Over 11 MB of data flows through menu images, order histories, and rider tracking updates.

7:00 PM. 458 requests. The dinner peak. This is when the platform truly shines. 32 unique visitors are active at this exact moment. They're not just browsing; they're ordering, tracking, and interacting. Our World Cup predictions are rolling in. Referral rewards are being claimed.

8:00 PM. 213 requests. The rush settles. Full bellies. Happy customers. 10 unique visitors are still active, maybe checking their order history, maybe planning tomorrow's lunch.

The Day in Numbers

Let's zoom out.

In just 24 hours:

Over 4,100 requests served
~350 unique visitors found us
90 MB of data delivered to hungry customers
Peak usage at 3 PM with 528 requests
Strong cache performance at 90% during peak times

But the numbers only tell half the story.

What Makes This Possible

Behind every request is a story.

A student in Lagos ordering their first laundry pickup
A vendor in Abuja managing their first corporate meal program
A rider in Port Harcourt checking their commission earnings
A user in Bangladesh searching for "foodmat app download" for the first time
A customer in Australia discovering food delivery from the other side of the world

We see the queries people search:

"foodmartex" — 60% click-through rate. They found us.
"foodmat site"—159 impressions. They're looking for us. We're getting there.
"iya ruka ile ife" — 2 impressions. Someone, somewhere, searching for something meaningful in their native tongue.

Every search, every click, every order—it's a signal. A sign that we're building something people need.

What Happens Next

The platform grows. The numbers go up. But the goal isn't just bigger numbers.

It's the 3 PM rush becoming 600 requests. It's the cache hit rate hitting 95%. It's the rating climbing from 3.67 to 4.5. It's the monthly active users jumping from 180 to 500.

It's making food delivery faster. Laundry simpler. Make corporate meals more accessible. Make referral rewards more exciting. World Cup predictions more fun.

It's watching a platform become a community.

The Invitation

We don't build this alone. Every user, every vendor, every rider—they're the heartbeat of the platform.

If you're reading this and you've ever used FoodMartex:

You were part of that 528-request peak at 3 PM
Your 3.67 average rating helps us get better
Your referral keeps the platform growing

And if you haven't tried us yet?

We're ready. The servers are waiting. The food is hot. The laundry is fresh. The World Cup predictions are open.

Come find us. Search "foodmartex." Be part of the story.

The Final Number

7:00 PM. The day's final peak: 458 requests. 32 unique visitors. 85% cache hit rate. 10.8 MB of data served.

And somewhere in Nigeria, someone just placed their first order.

The platform lives. The platform grows. The platform serves.

And tomorrow, it starts all over again.

We Built 6 Major Features in 30 Days (And Only Cried Twice)

Oge Obubu — Fri, 26 Jun 2026 16:12:11 +0000

The rule of thumb in software engineering is simple: under-promise and over-deliver. This June, we completely ignored that rule.

Our team looked at the calendar, looked at our product roadmap, and collectively decided that sleep was optional. Over the last 30 days, we didn't just ship updates; we practically rebuilt the marketplace engine while the plane was mid-flight.

If you've ever wondered what it looks like when a product team operates on pure adrenaline, espresso, and a shared dream, here is a peek behind the curtain of our craziest month yet.

🛑 The Chaos: What We Upended

We didn't just tweak the UI. We introduced entirely new business models into the ecosystem simultaneously.

The Pivot to Clean Clothes: We built an entire logistics lifecycle for laundry ordering from scratch. Express options, insurance, custom pickup/delivery windows, and real-time vendor tracking. We went from "food delivery" to "handling your delicate fabrics" in a matter of weeks.
Chasing the World Cup Hype: Capitalizing on cultural moments is hard. Capitalizing on them with software is harder. We launched a fully interactive World Cup prediction engine with live leaderboards and referral loops to capture the tournament energy.
The B2B Leap: We quietly opened a massive new revenue stream by launching our Corporate Meal Program, allowing companies to manage employee meal benefits directly through us.

Oh, and because our engineers apparently don't like weekends, we also revamped bulk ordering, overhauled our SMS campaign architecture, and added pending payment triggers.

🛠️ The Hardest Problems We Had to Solve

The "Happy Path" in software is a myth. Here are the realities we ran into that didn't make it into the official corporate slides:

1. The State Machine Nightmare
When you introduce laundry and bulk ordering, your standard "order lifecycle" breaks. A pizza goes from oven to rider to door. A laundry bag goes from customer to rider to vendor, sits for 48 hours, undergoes a status change (washing/drying), goes back to a different rider, and returns home. Designing a state machine that handles this without swallowing orders was an absolute brain-melter.

2. The Scaling Dilemma
Launching a viral prediction campaign means sudden, unpredictable spikes in database reads and writes every time a whistle blows. We spent a lot of time optimizing leaderboards and caching queries so an influx of football fans wouldn't accidentally bring down our checkout funnel.

🏆 The Big Wins (and Small Joys)

Despite the chaos, the ship didn't just float; it soared.

6 major features were pushed to production.

10+ Core UX Enhancements (including some highly satisfying balloon animations on the dashboard, because software should be fun).

Zero catastrophic downtime. What this actually means: Our customers have three times as many ways to use the platform, our corporate partners have an entirely new perk for their teams, and our vendors are unlocking revenue streams they didn't have on June 1st.

🔮 What’s Next (From the Safety of Staging)

We aren't done. Right now, our staging branch is heavy with code that's currently undergoing final stress testing. Automated rider matching for those complex laundry routes is around the corner, alongside advanced subscription order management.

To the engineering and product teams who lived on GitHub and Slack this month: thank you.

Now, if you'll excuse me, I'm going to go close 47 open browser tabs and sleep for a week. Or at least until Monday. 🚀

SMS in Nigeria Broke at 2 AM - So We Built a Multi-Channel Messaging Architecture That Routes Around Failure

Oge Obubu — Thu, 25 Jun 2026 21:29:17 +0000

The Problem
In Nigeria, SMS delivery is not guaranteed. Carriers drop messages, gateways go down, and your carefully crafted transactional alert silently vanishes into the void.

When you run a food delivery marketplace where:

A vendor needs to know about a new order within seconds
A rider needs pickup instructions to arrive on time
A customer's OTP must reach them before they abandon signup

…SMS reliability isn't nice-to-have. It's table stakes.

We started with one provider. We learned the hard way.

The Architecture
We now run two independent messaging services, each with different strengths:
Transactional SMS (primary)
→ KudiSMS service with error classification
→ Critical failures → developer alerts
→ Structured validation + phone number parsing
Escalation & multi-channel (secondary)
→ Termii service (SMS + WhatsApp + Voice)
→ Configurable per-channel toggles
→ Used for time-sensitive vendor/admin alerts

How they work together
KudiSMS handles the bulk of transactional traffic. Every order confirmation, OTP, and status update flows through a dedicated notification channel backed by KudiSMS. The service has explicit error classification, retryable failures vs critical failures, and logs them differently. Critical failures trigger alerts so someone knows immediately.

Termii covers the gaps. It supports SMS, WhatsApp, and Voice calls through a single API. For order escalation, a job dispatches alerts through multiple channels:

SMS to the vendor's phone (first attempt)
WhatsApp if the vendor's preferred channel is configured
Voice call as a last resort for urgent orders
Admin escalation - if the vendor hasn't responded after N minutes, admins get WhatsApp + Voice alerts too

Each channel can be toggled independently via configuration. This means we can disable SMS for maintenance without affecting WhatsApp or Voice delivery.

The subtle design decisions that matter
Phone number normalisation is separate per service. Nigerian numbers come in different formats (080…, +23480…, 23480…). Each service normalises independently; if one has a bug, the other still works.
Validation fails fast, not silently. KudiSMS validates configuration on every request and throws immediately if credentials are missing. A misconfigured service fails loudly rather than quietly dropping messages.
Errors are classified by severity. We distinguish between retryable failures (network blips) and critical failures (auth issues, invalid responses). Only critical errors wake someone up. This prevents alert fatigue from transient network hiccups.

Escalation has state awareness. The order escalation job checks whether the order has already been accepted before sending an alert. It won't spam a vendor who already picked up the phone and accepted the order.
What this looks like in production

A vendor gets a new order alert:

KudiSMS sends the transactional SMS → delivered, great
If KudiSMS fails → the error is classified and logged, and a developer gets an alert
Meanwhile, the escalation timer starts ticking
After N minutes without acceptance → Termii sends a WhatsApp message
After N more minutes → Termii makes a voice call
After N more minutes → admins get notified via WhatsApp and voice The system doesn't just fail over. It escalates through increasingly intrusive channels.

Lessons Learned

Redundancy means independent failure modes. Two SMS providers using the same carrier or the same API pattern will fail together. Our providers have different infrastructure.
Multi-channel is better than multi-provider. WhatsApp and Voice don't compete with SMS carriers. Adding channels gives you genuinely orthogonal delivery paths.
Alert fatigue kills incident response. We spent as much time designing when not to alert as we did building the alerting itself. Classify errors by severity and keep the noisy ones quiet.
Test the fallback. If you've never seen your secondary provider actually handle traffic, you don't have a fallback. We periodically route test traffic through Termii to validate the path.

The Frontend Engineer Will Not Be Replaced by AI

Oge Obubu — Tue, 23 Jun 2026 18:53:03 +0000

Prologue: The 2 AM Deployment

It was 2:17 AM. I was staring at a terminal, sweat beading on my forehead, waiting for a deployment to finish. The feature? A simple discount coupon flow. Three forms, a validation step, and a confirmation screen. Nothing special by any standard.

But this was a grocery platform. And in the morning, thousands of people would wake up, open this app, and try to feed their families. If the coupon didn't apply correctly, someone would overpay. Someone would be frustrated. Someone might not be able to afford what they needed that week.

The deployment succeeded. I sat back, exhaled, and realized something I've never forgotten: the code I write has weight. It's not abstract. It's not just syntax. It's the difference between someone eating dinner and someone going hungry. Between a business staying open and closing. Between a delivery arriving on time or a child missing their school lunch.

Five years later, I've shipped hundreds of features. Some small ones. Some that moved millions in revenue. But that 2 AM deployment, that moment of realizing my code mattered, is the fire that's kept me going.

And now I'm watching the news tell an entire generation of aspiring engineers, "AI is coming for your job. Don't bother learning to code. It's over."*

They're wrong. Profoundly, dangerously, completely wrong.

Let me tell you why.

Part I: The Fear, The Headlines, and The Misunderstanding

Walk into any tech X (formerly Twitter) space, open any LinkedIn feed, scroll through any YouTube comment section, and you'll find the same narrative:

"Cursor wrote this entire app."
"V0 generates production-ready UI in seconds."
"Why hire a frontend engineer when Claude can build your entire landing page?"
"Frontend is dead."

I get it. It's scary. When I first saw an AI generate a functional React component from a sentence, my stomach dropped. I'd spent years learning to write that exact thing. Was it all for nothing?

Here's what I learned: AI generates output. It does not generate ownership.

Anyone can prompt. Almost no one can ship.

A generated component is just a sketch. It has no context. It doesn't know why the button is orange instead of blue. It doesn't know that the loading state needs to appear for exactly 300 milliseconds, not 200, not 400, because user testing showed that 300ms is the sweet spot between perceived speed and perceived effort.

It doesn't know that the disabled submit button should show a tooltip explaining why it's disabled. It doesn't know that the error message should say, "This email is already registered. Did you forget your password? Let us help you reset it" instead of "Error: duplicate entry."

AI doesn't know these things because these things are not in the training data. They're in the trenches. They're in the user testing sessions. They're in the 2 AM realizations. They're in the conversations with product managers and customer support agents and actual human beings who use what you build.

The fear is real. The headline is wrong.

Part II: What Five Years of Shipping Actually Taught Me

I've spent over five years building full-stack applications. I've built e-commerce platforms that connect thousands of vendors with hundreds of thousands of customers. I've built real-time logistics systems that track deliveries down to the exact GPS coordinate. I've built promotional campaign engines that reward customers for predictions and referrals. I've built admin dashboards that give businesses superpowers, the ability to see, understand, and act on their operations in ways they never could before.

And here's what I've learned about what matters:

1. Syntax is the cheapest thing you own

When I started, I thought knowing JavaScript deeply was the secret sauce. Then I thought React. Then TypeScript. Then the latest state management library. Then the hottest CSS framework.

Every six months, the "essential" tool changed.

If I'd tied my identity to syntax, I'd have been replaced ten times over. Instead, I tied my identity to something AI can't touch: the ability to translate human needs into technical solutions.

Here's what I mean: a customer doesn't care if you used Redux or Zustand or signals or context. They care that when they tap "Checkout," their order goes through. They care that when they're confused, the interface guides them. They care that when something breaks, the system doesn't punish them.

A business owner doesn't care if your admin panel is built with React or Vue or Svelte or vanilla HTML. They care that they can find the data they need in three clicks instead of thirty. They care that their team can onboard in an hour instead of a week.

Your framework is temporary. Your ability to understand what humans need? That's permanent.

2. The hard problems are not technical

Five years ago, I thought the hardest problems were technical. Architecture. Performance. Edge cases.

Today, I know the hardest problems are human:

How do you tell a user their order failed without making them panic?
How do you build a dashboard that a non-technical admin can use confidently?
How do you design a referral flow that feels like a gift, not a transaction?
How do you handle a vendor who accidentally set their inventory to zero and needs to fix it fast?
How do you show a customer their delivery is delayed without making them angry at the rider?

Every single one of these is a frontend problem. Every single one requires empathy. Every single one requires understanding context, emotion, and real-world consequences.

AI can generate the form. It cannot generate trust.

3. The best code is code you don't write

This is the paradox of experience: the more you know, the less you build.

Junior me would write 500 lines to solve a problem. Today, I write 50. Not because I'm lazier, but because I've learned that every line of code is a liability. Every component is something that needs to be maintained, tested, and understood by the next person.

The most valuable skill I've developed isn't writing code faster. It's knowing what not to build.

Do we need a custom date picker, or should we use the library we already have?
Does this need to be a new page, or can it be a modal?
Do we need real-time updates, or is polling every 30 seconds good enough?
Does this feature need to exist at all, or are we solving a problem nobody has?

AI will never ask those questions. It will generate whatever you prompt. It has no judgment. It has no experience of maintaining a codebase for three years and knowing exactly which dependencies have caused problems and which patterns lead to bugs.

That judgment, the hard-earned wisdom of having shipped, failed, fixed, and shipped again, is irreplaceable.

Part III: A Tour Through Real Features I've Built

Let me walk you through a few real features I've built. Not to impress you, but to show you the difference between what AI generates and what an engineer actually does.

The Promotional Campaign Engine

A client wanted a promotional campaign: customers predict match scores and refer friends. Correct predictions and successful referrals earn rewards.

An AI could generate the CRUD. The forms. The tables.

But here's what the AI wouldn't know:

The admin needs six different tabs because they check different data at different frequencies. Settings once. Matches daily. Winners hourly. Putting them all on one page would be chaos.
The prediction flow needs to show teams by name — but the database stores them inconsistently. Sometimes home_team. Sometimes home_team_name. Sometimes home. The AI would pick one. I had to write code that handles all three, because the backend team was still migrating. That's not syntax. That's context.
The referral progress bar needs to handle multiple data sources. Progress could come from a dedicated endpoint, or it could be calculated from the entries list, or it could come from a cached value. The AI would assume one shape. Real APIs change. I had to write code that gracefully degrades through every possible source.
The status badge needs to be green for "correct" but also for "qualified" and "rewarded" and "won." And orange for "pending" but not for "incorrect." And red for "incorrect" but also for "lost" and "expired." These aren't technical decisions. They're human decisions, what does each status mean to the person reading it?

AI generates output. Engineers generate meaning.

The Real-Time Logistics Dashboard

Trucks move across a city. Customers refresh their browsers, waiting for their groceries. The status needs to update without a page reload. The driver's location needs to show on a map. The estimated arrival needs to be accurate.

An AI could wire up WebSockets and drop a marker on a map.

But here's what the AI wouldn't know:

The customer is anxious. Every second the spinner shows, their stress increases. So the UI needs to show something, not just a loading state, but a meaningful status: "Your rider is at the store" → "Your rider is packing your order" → "Your rider is on the way" → "Your rider is 3 minutes away." Each step is a small reassurance.
The rider's GPS updates every 5 seconds, but we should only re-render the map every 15 seconds. Because re-rendering every 5 seconds drains battery, creates visual noise, and makes the UI feel jittery. The AI doesn't know about battery. It doesn't know about visual comfort.
When the rider is late, the customer's frustration needs to be directed somewhere productive. So we show "Your rider is delayed by traffic," not "ETA updated." We frame the delay as external, not as a system failure. This is UX psychology, not code.
The admin needs to see all active deliveries on one screen with color-coded status—green for on-time, yellow for borderline, and red for late. A simple dashboard that takes 10 minutes to build but saves hours of phone calls from anxious customers.

None of this is in any training data. It's all learned from watching real users struggle with real interfaces.

The Vendor Onboarding Flow

A marketplace lives and dies by its supply side. If vendors can't onboard quickly, the catalog stays empty. If the catalog is empty, customers don't come.

The onboarding form needed to collect business details, bank information, food safety certification, delivery zones, opening hours, and menu items. That's about 50 fields spread across 6 steps.

An AI could generate a multi-step form.

But here's what the AI wouldn't know:

Vendors are busy. They're running a business. The form needs to save progress at every step so they can come back later. The AI wouldn't think about partial saves because it's never been interrupted by a customer walking into a store while filling out a form.
The bank details step is stressful. People get nervous entering financial information. The UI needs to look secure, padlock icons, reassuring copy, and clear explanations of why each field is needed. The AI wouldn't know that the visual design of a form field can change someone's emotional state.
The certification upload step has a specific failure mode: vendors take photos of documents on their phones, and those photos are often sideways, blurry, or too large. The frontend needs to handle orientation correction, compression, and clear error messages about quality requirements. The AI wouldn't know that 30% of users would upload a sideways image.
When a vendor gets stuck, they don't email support. They just leave. So every step needs inline validation that explains what's wrong and how to fix it, not just "invalid input." The AI would generate generic error messages. Real vendors need specific guidance.

The Admin Dashboard

The most complex thing I've ever built isn't a customer-facing feature. It's the tool that runs behind the scenes.

Admin dashboards are where business operations happen. They're where customer support agents resolve issues. Where finance teams track payments. Where operations managers monitor deliveries. Where marketing teams launch campaigns.

An AI could generate a table with filters.

But here's what the AI wouldn't know:

Every admin user has a different workflow. The support agent needs to search by customer name. The finance person needs to filter by date range and payment status. The operations manager needs to see everything sorted by urgency. One dashboard needs to serve multiple mental models.
Admins are under pressure. They're handling customer complaints, vendor disputes, and delivery delays. The UI needs to be fast, not just technically fast, but cognitively fast. Every extra click, every confusing label, every slow filter adds to their stress. The AI wouldn't know that an extra 2 seconds of load time during peak hours means 50 fewer tickets resolved.
The most important data needs to be most visible. Not everything in the dashboard is equally important. The orders that are 2 hours overdue matter more than the ones that were just placed. The vendors who haven't been paid in 3 weeks matter more than the ones who were paid yesterday. The AI would treat all data equally. Real dashboards need to tell a story about what needs attention right now.
Admins make mistakes. They accidentally delete records, change values they shouldn't, and take actions they can't undo. Every destructive action needs confirmation, undo capability, or, at minimum, a clear audit trail. The AI wouldn't think about undo because it's never accidentally deleted a production record at 6 PM on a Friday.

Part IV: The Skills That Matter Now (And Will Matter More)

If you're an aspiring frontend engineer reading this, you're probably wondering, "What should I actually learn?"*

Let me be specific.

The Skills AI Cannot Amplify (That You Must Own)

1. Problem decomposition

Before you write a single line of code, you need to understand the problem. Not the technical problem, the human problem.

"The checkout page is too slow" is not a problem statement. It's a symptom.

The real problem might be "Users abandon the checkout when they see unexpected shipping costs."*

The real solution might not be a faster checkout. It might be showing shipping costs earlier. It might be free shipping over a certain amount. It might be a progress bar that shows "add ₦1,000 more for free delivery."

AI can optimize the checkout. It cannot diagnose the real problem.

2. Communication across disciplines

Every feature you build requires translating between worlds. The business team speaks in revenue and conversion. The design team speaks in flows and pixels. The backend team speaks in APIs and data models. The customer support team speaks in tickets and pain points.

Your job as a frontend engineer is to speak all these languages and translate between them. You're the bridge. Without you, each team operates in isolation. With you, the entire company moves in one direction.

AI cannot attend a meeting, understand what a product manager is really asking for, and translate that into technical requirements. It can't read between the lines of "can we make this pop?" and understand that the PM means "the conversion rate on this button is too low, and we need to make it more prominent."

3. Judgment about tradeoffs

Every engineering decision is a tradeoff:

Speed vs. quality
Custom vs. off-the-shelf
Build vs. buy
Ship now vs. ship right
Optimize for the 90% case or handle the 10% edge case

There is no objectively correct answer. Every decision depends on context: the team size, the business stage, the user base, the technical debt already accumulated, the timeline, and the budget.

AI cannot judge tradeoffs. It can only optimize for what you tell it to optimize for. And most of the time, you don't know what to optimize for until you've made the wrong choice a few times and learned from it.

4. Ownership and accountability

This is the biggest one.

When AI generates code and it breaks, who fixes it? When a bug slips into production at 11 PM on a Friday, who's debugging? When a customer's order fails because of a frontend validation edge case, who's explaining to the support team what happened?

You. Every time.

Ownership means this is my code, my users, and my responsibility. It means staying up late to fix the bug. It means apologizing when you break something. It means learning from every failure and making sure it doesn't happen again.

AI has no skin in the game. It doesn't get paged at 3 AM. It doesn't have to explain to a CEO why revenue dropped. It doesn't care.

You do. And that caring, that deep, exhausting, beautiful commitment to your users, is the most valuable thing you bring to any team.

The Skills AI Can Amplify (That You Should Still Master)

1. Speed of iteration

AI can generate a prototype in seconds. Use this. Generate the first draft, then apply your judgment to refine it. You get to skip the boring scaffolding and focus on what matters: the details, the edge cases, the polish.

But here's the trap: if you can't judge whether the AI output is good, you're stuck. You need to know enough to be a critic, not just a prompter.

2. Code generation for known patterns

Any pattern you've implemented ten times, forms, tables, CRUD endpoints, or auth flows, AI can generate competently. Use it. Free up your brain for the novel problems.

But if you've never implemented these patterns yourself, you won't know when the AI generates something subtly wrong. The worst-case scenario isn't obvious bugs. It's subtle bugs that look correct but fail under specific conditions.

3. Exploration and learning

AI is phenomenal for answering "how do I do X in Y framework?" It compresses hours of documentation scrolling into seconds. Use it to learn faster.

But don't confuse knowing how to prompt for an answer with understanding the answer. Real understanding comes from implementing, debugging, and shipping.

Part V: A Letter to the Aspiring Engineer

Dear future engineer,

I know it's scary out there. I know the headlines are loud. I know every day brings a new announcement about AI replacing some part of our craft.

But here's the truth that nobody's saying loudly enough:

The demand for people who can ship real products, understand real users, and solve real problems is higher than it has ever been.

Yes, the entry barrier has shifted. The junior roles that were about "write this component" are disappearing. But the roles that require judgment, empathy, and ownership are growing. They pay more. They matter more. And they're harder to fill.

Here's my advice:

Build things that matter.

Not another todo app. Not another weather widget. Build something that a real human being would use. A tool for a local business. A helper for a family member. A dashboard for a friend's startup.

When you build for real users, you learn things no tutorial can teach:

You learn that your beautiful architecture doesn't matter if the page takes 3 seconds to load on a phone
You learn that your clever CSS animation makes some users nauseous
You learn that what you thought was clear is confusing to everyone else
You learn that shipping imperfect code today is better than shipping perfect code next month
You learn that the joy of building isn't in the technology, but in watching someone use what you made and seeing their face light up

Read code. Read a lot of it.

Read the code of open-source projects you admire. Read your dependencies. Read the pull requests of senior engineers. The more code you read, the more patterns you absorb. And the more patterns you absorb, the better your judgment becomes.

AI reads all the code. But it doesn't understand any of it. It doesn't know which patterns lead to maintainable codebases and which lead to spaghetti. It doesn't know which abstractions are worth the complexity and which aren't.

That understanding only comes from reading, writing, and shipping code over years.

Find a mentor (or be one).

The best engineers I know all have one thing in common: they learned from someone more experienced. Not from a bootcamp. Not from a course. From someone who sat next to them, looked at their code, and said, "Here's a better way."

If you're early in your career, find someone who's been shipping for a decade and ask them questions. Most senior engineers love mentoring. We remember what it was like to feel lost, and we want to help.

If you're experienced, mentor someone. Teaching forces you to articulate what you know, which deepens your own understanding. And watching someone grow is one of the most satisfying experiences in this field.

Embrace the boring.

The hottest framework, the newest pattern, the most elegant architecture, none of it matters if the product doesn't work.

The best code I've written is boring code. Simple components. Clear data flows. Predictable patterns. Nothing clever. Nothing impressive. Just reliable, maintainable, understandable code that does what it's supposed to do.

AI loves clever code. AI generates interesting solutions. But interesting is not what users need. They need reliability. They need boring. They need code that works at 2 AM when their order depends on it.

Don't compete with AI. Use it.

The worst strategy is to pretend AI doesn't exist. The second-worst strategy is to let AI do all your thinking.

The best strategy is AI handling the boilerplate. You handle the meaning.

Use AI to generate your tests. Use it to catch your edge cases. Use it to explore alternative approaches. But never let it make the final judgment call. That's yours. That's always been yours.

Part VI: Why Frontend Matters More Than Ever

Here's something nobody talks about:

The frontend is where value is delivered.

The backend is where data lives. The database is where information is stored. The APIs are where logic executes. But none of that matters if a human being can't access it.

Every dollar your company makes passes through the frontend. Every customer interaction happens on the frontend. Every time someone chooses your product over a competitor's, they're choosing your frontend experience.

The frontend is not "just UI." It's the moment of truth, the place where all the backend complexity, all the business logic, all the data processing, and all the engineering effort become real for a human being.

If the frontend is confusing, the product is confusing. If the frontend is slow, the product is slow. If the frontend is untrustworthy, the product is untrustworthy.

The frontend engineer is not a "UI developer." You are the steward of the user's trust. Every pixel, every animation, every micro-interaction, every loading state, and every error message, they all either build trust or erode it.

AI can generate pixels. It cannot generate trust.

Trust is earned through consistency. Through reliability. Through understanding what your users fear and addressing it before they have to ask. Through shipping features that make your users' lives measurably better.

That's not a technical challenge.

That's a human one.

Part VII: The Architecture of Empathy

Let me share something I've never written down before.

There's a moment in every project where the code becomes invisible. Where you stop thinking about React components and API calls and start thinking about the human being on the other end of the connection.

It usually happens around 3 AM, after you've fixed the same bug three times.

You realize that the bug wasn't technical. It was emotional.

The user wasn't confused because the UI was unclear. They were confused because they were stressed, distracted, and in a hurry, and the interface demanded more attention than they had to give.

The solution wasn't a better error message. It was removing the need for the error message entirely.

This is what I call the architecture of empathy.

It's the realization that every interface is a conversation. Every button is a question. Every confirmation dialog is a reassurance. Every loading state is a promise.

And like any good conversation, the best interfaces are the ones where the other person feels understood.

Here's how you build with empathy:

Know who you're building for

Not "users." Not "customers." Specific people with specific contexts.

The cashier is processing orders at 7 PM after a 10-hour shift. The single parent ordering groceries while holding a toddler. The admin who's been doing data entry for 4 hours and desperately needs this one filter to work.

Every time you make a UX decision, ask: Would this help the person who's tired, stressed, distracted, and just wants to get this done?

Know what they're afraid of

Users come to every interface with fear:

Will I lose my data?
Will I be charged twice?
Will I make a mistake I can't undo?
Will this take too long?
Will I look stupid?

Your job is to address every fear before they have to articulate it. Show them their data is saved. Show them the transaction was successful. Let them undo mistakes. Make the fast parts visible. Design error states that don't blame the user.

Know what they're trying to do

Nobody wakes up wanting to use your app. They wake up wanting to feed their family, run their business, or make it through their shift.

Your app is a means to an end.

Every feature should either get them closer to their goal faster or reduce the friction of getting there. If it doesn't do either, it doesn't belong.

Part VIII: The Real Future of Frontend

I've been doing this for over five years. I've built things I'm proud of and things I've learned from. I've stayed up late, shipped under pressure, debugged impossible bugs, and felt the incomparable joy of watching someone use something I built and seeing it make their day better.

And I can tell you with absolute certainty: the future of frontend engineering is not in writing more code. It's in understanding people better.

The AI revolution is not the end of our craft. It's the liberation of our craft.

We get to stop writing scaffolding and start designing experiences. We get to stop debugging CSS and start debugging user journeys. We get to stop optimizing render cycles and start optimizing for human delight.

The tools will change. They always do. The frameworks will evolve. They always will. AI will get smarter. It's already smart, and it's only going to get smarter.

But the fundamental equation hasn't changed:

Technology + Empathy = Value

AI brings the technology.

Only you bring empathy.

Only you can sit with a user, watch them struggle, and understand what they need. Only you can stare at a screen at 2 AM and realize that a single pixel adjustment will save thousands of people a moment of confusion. Only you can look at a business requirement and translate it into an interface that feels natural, intuitive, even joyful.

That's not going away. It's becoming more valuable every day.

Epilogue: The 2 AM Deployment, Revisited

It's 2 AM again, years later.

I'm watching a deployment pipeline run. This time it's a major feature, a campaign engine that will run for weeks, involving thousands of customers predicting scores, referring friends, and earning rewards.

The stakes are higher. The system is more complex. The audience is bigger.

And yet, the feeling is the same: this matters.

Somewhere out there, a customer will wake up, open this app, and see their prediction was correct. They'll smile. They'll tell a friend. They'll feel good about using this product.

Somewhere out there, an admin will log into the dashboard, see the referral leaderboard, and know exactly who to reward. They'll feel in control. They'll trust the system.

Somewhere out there, a business owner will look at the campaign metrics and see that revenue went up because more customers engaged, because the experience felt good, because someone, an engineer, cared about the details.

That engineer was me.

And for the next generation reading this: that engineer will be you.

Not AI. You.

The AI will write the components. The AI will handle the boilerplate. The AI will catch the edge cases.

But only you can write the future.

Only you can care enough to make it matter.

Only you can look at a blank screen and imagine something that doesn't exist yet, something that will make someone's life measurably better, and then build it, ship it, and watch it change the world, one interface at a time.

That's not a skill AI can learn.

That's a choice only a human can make.

So make it.

Build something that matters. Ship it imperfectly. Learn from the failures. Celebrate the wins. And never, ever let anyone tell you that what you do is "just frontend."

What you do is where value becomes real.

What you do is where technology meets humanity.

What you do is magic. It always has been. And AI? It's just another tool in your magic kit.

The real magician?

Still you.

Always you.

I've been building full-stack applications for over five years, e-commerce platforms, logistics systems, promotional engines, and admin dashboards. I've shipped code that moved millions and code that mattered to exactly one person. If you're early in your journey and wondering whether this path is worth it, it is. If you're experienced and wondering whether your skills still matter, they do. More than ever.

What are you building? I'd love to see it.

Follow Me
X: @ogeobubu
GitHub: @ogeobubu
Instagram: @ogeobubu
Threads: @ogeobubu

How We Scaled from 0 to 164 Monthly Active Users in 28 Days (And What We Learned)

Oge Obubu — Sun, 21 Jun 2026 20:35:55 +0000

The story of Foodmartex's biggest week yet and the surprising lessons that came with it.

The Night Everything Changed

It was 2:37 AM on a Wednesday when I refreshed our analytics dashboard for the hundredth time that week. My eyes were burning, but the numbers told a story I couldn't look away from. Something was happening.

Our app had just hit 164 monthly active users.

For a platform that was practically invisible just months ago, this was the moment we'd been working toward. But here's the thing about growth: it never comes from where you expect it. And the week of June 15–21, 2026, taught me lessons I won't forget.

The Traffic That Didn't Make Sense

Let me start with the weirdest part of our week.

According to our analytics, we should have been celebrating a massive spike in Nigerian traffic. After all, Nigeria is our home market. It's where our earliest users came from, where our brand recognition is strongest, and where we've invested the most energy.

And sure enough, Nigeria showed up. 3,183 requests in just 24 hours.

But here's where it gets interesting.

The Netherlands, a country we've barely marketed to, was right on Nigeria's heels with 1,953 requests. That's not a typo. A country thousands of miles away, where we have zero brand presence, was sending almost as much traffic as our core market.

The United States came in third with 466 requests, followed by the UK at 416 and Germany at 107.

I sat there staring at this data, trying to make sense of it. Was it bots? Scrapers? Some viral post we didn't know about? Or was it something else entirely, the early signs of unexpected market interest?

We're still investigating. But here's what I've learned: growth doesn't always knock on the door you expect it to. Sometimes it kicks down a window in Amsterdam.

The Misspelling That Changed Everything

If you've ever launched a product, you know the agony of watching people misspell your name.

"foodmat.site", not our domain, but close enough to hurt.

In the past week alone, this misspelling and its variations generated over 1,300 impressions on Google. That's 1,300 people searching for something that sounds like us, looks like us, but isn't quite us.

Here's the painful part: our click-through rate on these terms was abysmal. People were searching, seeing results, and moving on. They wanted Foodmartex. They typed something slightly wrong. And we were nowhere to be found.

But the moment they typed "foodmartex" correctly? We ranked number one with a click-through rate of 67.74%. One out of every three people searching for our exact name clicked through.

That's the power of branding. But it's also the danger of assumptions. We assumed people would find us. We assumed they'd type correctly. We assumed wrong.

The lesson here is simple: your customers are typing your name wrong. Are you capturing those searches? Or are you letting them slip through your fingers?

The App That Refused to Crash

Now let's talk about something I'm genuinely proud of.

Our mobile app has a perfect 5.00-star rating on Google Play. I know, I know; early days, small sample size. But here's what that rating actually represents:

Zero crashes. Zero ANR (Application Not Responding) errors. Zero stability issues.

In a world where users will abandon an app after just one bad experience, we've built something that just works. And over the last 28 days, we've seen that stability translate into real growth:

75 new device acquisitions (up 19%)
52 first opens (up 11%)
164 monthly active users (up 32%)
312 total installs

Those numbers might not sound like much to a giant tech company. But to us? They represent 312 people who trusted us enough to install our app. 164 people who came back. 52 people who opened it for the very first time.

Every one of those people made a choice. And we're determined to make sure it is the right one.

The Week That Felt Like a Year

Behind these numbers, our engineering team was doing something remarkable.

In just seven days, we built and launched features that would normally take a month:

We made laundry ordering production-ready. Not just "it works," but full lifecycle support. Customers can order, track, and cancel. Vendors can confirm and manage. Riders get matched automatically and settled fairly.

We built an admin SMS system from scratch. Thousands of messages queued, delivered, and tracked. With a dashboard to see exactly what's working and what isn't. (And yes, we immediately rotated our API tokens when we realized they were visible. Lesson learned.)

We made our payment math flawless. Rewards expire automatically. Referrals credit correctly. Riders get exactly what they're owed, and the company keeps exactly what it's owed. No rounding errors. No edge cases. No surprises.

And we did all of this while maintaining zero downtime and zero user-facing bugs.

The 946 People Who Matter Most

Here's a number I keep coming back to: 946 unique visitors to our website in the last 7 days.

Not all of them became users. Not all of them converted. But they all came. They all looked. They all gave us a chance.

361 of them came on our best day. 85 is our slowest.

That spread tells me something important: our traffic isn't consistent yet. We're not a steady stream. We're waves crashing against the shore. Some days, the tide is high. Other days, it's a trickle.

But here's the thing about waves: they keep coming.

And as long as people keep searching, keep typing, and keep trying to find us, we'll keep building. We'll fix the misspellings. We'll capture the stray traffic. We'll make our platform so good that no one ever has to search for a competitor again.

What We Learned (So You Don't Have To)

If you're building something, an app, a platform, or a dream, here's what this week taught me:

1. Your customers are searching for you in the wrong way.
Find those misspellings. Capture them. Don't let a typo stand between someone and your product.

2. Growth doesn't come from where you expect it.
Nigeria is our core. But the Netherlands showed up uninvited. Don't ignore the unexpected. It might be your next market.

3. Stability is your most powerful marketing tool.
A 5-star rating is worth more than any ad campaign. Build something that doesn't break. People will notice.

4. Your team is capable of incredible things in a single week.
19 commits. 7 days. 3 major features. Don't underestimate what focused people can accomplish.

5. Growth is a numbers game, but it's also a people game.
946 visitors. 312 installs. 164 active users. Behind every number is someone who took a chance on us. We don't forget that.

The Road Ahead

We're not a giant company yet. We're not even close to where we want to be. But we're growing. We're learning. We're building.

And that's the point, isn't it?

The week of June 15–21, 2026, was our best week yet. But it's not going to be our best week forever. Because next week, we'll be better. And the week after that, better still.

We're Foodmartex. We're building the future of everyday convenience. And we're just getting started.

Stay hungry. Stay curious. And for the love of everything, please type our name correctly.

P.S. — If you're one of the 312 people who installed our app this month, thank you. You made this week unforgettable. If you're not, what are you waiting for? Foodmartex App

P.P.S. — To the person in the Netherlands who's been refreshing our site all week: we see you. We appreciate you. We'd love to know what brought you here. Drop us a comment below.

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.

DEV Community: Oge Obubu

Stop Using `useEffect` for Data Fetching—Please, I Beg You

The Scene

The Problem with useEffect for Data Fetching

Enter TanStack Query (Formerly React Query)

What TanStack Query Gives You That useEffect Never Will

The Real Difference

A Practical Example

But Wait—Is useEffect Completely Obsolete?

What You Gain by Making the Switch

A Word for the Sceptics

The Bottom Line

Your Next Step

We Built a Super-App in 30 Days. Here's the Chaos Nobody Saw.

Day 1: "It's Just a Food App… Right?"

Week 1: The Multi-Service Monster Awakens

Week 2: The Features That Made People Say "Wait, This App Does THAT?"

The Meal Subscription Engine

Corporate Meal Plans (Staff Lunch)

Global Search That Actually Finds Things

Week 3: Gamification, Predictions, and the Spin Wheel That Broke Our Brains

The Spin Wheel

FIFA 2026 World Cup Predictions

Week 4: Payments, Parcels, and the Stuff That Actually Matters

Seamless In-App Payments

Parcel Delivery, Done Right

Live Delivery Tracking

The Invisible Architecture Nobody Talks About

Guest-to-Authenticated Cart Merging

Network Resilience

The Numbers

What's Next?

I Built a Super-App Backend in 2 Weeks. Here's What Nobody Tells You About the Chaos.

Day 1: "How hard can it be?"

The Number That Keeps Me Up at Night

The Commission Problem Nobody Warned You About

Notifications: The Invisible Monster

The Payment Resurrection

Real-Time Order Tracking

The Feature Toggle That Saved the Day

What I Learned in 14 Days

The Numbers

The Architecture

What's Next

The 4 PM Rush: A Day Inside a Growing Food Tech Platform

The Quiet Before the Storm

The Morning Rush

The Lunch Explosion

The Evening Surge

The Day in Numbers

What Makes This Possible

What Happens Next

The Invitation

The Final Number

We Built 6 Major Features in 30 Days (And Only Cried Twice)

🛑 The Chaos: What We Upended

🛠️ The Hardest Problems We Had to Solve

🏆 The Big Wins (and Small Joys)

🔮 What’s Next (From the Safety of Staging)

SMS in Nigeria Broke at 2 AM - So We Built a Multi-Channel Messaging Architecture That Routes Around Failure

The Frontend Engineer Will Not Be Replaced by AI

Prologue: The 2 AM Deployment

Part I: The Fear, The Headlines, and The Misunderstanding

Part II: What Five Years of Shipping Actually Taught Me

1. Syntax is the cheapest thing you own

2. The hard problems are not technical

3. The best code is code you don't write

Part III: A Tour Through Real Features I've Built

The Promotional Campaign Engine

The Real-Time Logistics Dashboard

The Vendor Onboarding Flow

The Admin Dashboard

Part IV: The Skills That Matter Now (And Will Matter More)

The Skills AI Cannot Amplify (That You Must Own)

1. Problem decomposition

2. Communication across disciplines

3. Judgment about tradeoffs

4. Ownership and accountability

The Skills AI Can Amplify (That You Should Still Master)

1. Speed of iteration

The Problem with `useEffect` for Data Fetching

What TanStack Query Gives You That `useEffect` Never Will

But Wait—Is `useEffect` Completely Obsolete?