DEV Community: Oge Obubu

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.

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.