Have you ever noticed how the internet is just becoming AI talking to AI?
You get an email that was definitely written by ChatGPT. You use Gemini to summarize it and spit out a polite reply, and you hit send without even reading it. Then you jump on LinkedIn, see a totally AI-generated post, screenshot it, ask Claude for a spicy reply, and post that. Even with jobs, you use AI to write your resume, and the recruiter uses an AI tool to reject it.
It’s wild. The internet is turning into this weird loop of bots just feeding off each other.
But honestly, the social media and email stuff is just noise. The craziest part is what’s happening right now in our codebases.
We’re literally at the point of vibe coding. An AI agent picks up a ticket, writes the logic, and opens a PR. And instead of a senior dev pulling the branch to check it, another AI agent reviews it, approves it, and merges it straight to main.
The actual code running things is being written, reviewed, and deployed without a human ever looking at it. The machine is literally building the machine.
As someone who spends a lot of time writing “beautiful” code, this feels like a massive shift. Code used to be how we talked to the computer. Now, the bots are doing the talking.
It pushes us into a weird spot. We aren’t really coders in the traditional sense anymore; we’re more like system wardens. We don’t have to stress over a blank screen or basic syntax, but now we have the massive headache of babysitting a synthetic system to make sure some AI doesn’t hallucinate a bug that brings the whole architecture down. We traded the typing for the stress of constant oversight.
So, does this mean we’re just spectators now?
I think we are, but only if we try to compete at the boilerplate level.
An AI agent can merge a PR in seconds, but it has no idea if the infrastructure it just built actually solves a problem for real people in the local market. It can write a clean function, but it can’t tell a genuine story or figure out what a business actually needs to survive.
The internet is definitely running on autopilot, but deciding where to steer it? That’s still on us. We just need to stop stressing over the individual bricks and focus on what we’re actually trying to build.

What actually separates a senior engineer from the pack? It’s not just writing features; it’s error handling. It’s optimizing a system to fail gracefully.
Think about the lifecycle of a single request. When it depends on an external network call, do you just try it once, throw an error, and hope the user hits refresh? Or do you build in idempotent retry mechanisms and handle downstream server failures?
What happens if a database connection drops mid-query? What’s the fallback when the DB is entirely unavailable? From an operating system process malfunctioning to complete memory or disk exhaustion, computers are inherently prone to failure.
The defining trait of a mature engineer is the assumption that things will go wrong. You have to design systems to be fault-tolerant, ensuring they can recover when the inevitable happens.
At the end of the day, software engineering might just be the art of preventing computers from failing.

I’ve never quite bought into the hype of the “zero-oversight” AI developer.
If you spend five minutes on tech social media, you’ll see developers bragging about giving Claude or Gemini full access to their codebase. They talk about letting the AI write entire features, merging the pull requests, and moving on without a second thought.
But honestly? I still haven’t gotten over the feeling that the AI is eventually going to mess me up.
I tried it once, letting AI completely handle a non-critical feature for an internal tool without my usual deep, manual review. I didn’t feel the rush of 10x productivity. Instead, I felt a sudden drop in confidence. Even though it was low-stakes, there was this lingering, mild anxiety when it went live. Did I catch every edge case? Does it actually do what I think it does? It highlighted the psychological trade-off of the modern stack: you might save a few hours of typing, but you buy yourself days of low-grade panic waiting for a bug report.

This isn’t just about developer pride; it’s about strategic risk. AI has produced some incredible software, and I’m more than happy to let it do whatever it pleases with the frontend. If a UI component breaks or a layout shifts, it’s a visual annoyance that can be quickly patched.
But the backend is a completely different story.
When you are building financial systems, when your platform is actively processing real money on a daily basis, the stakes change completely. I honestly still struggle with the concept of letting an LLM write critical logic for the core engine of the financial systems I work on, including SusuPaa. In fintech, a backend hallucination isn’t just a broken div; it’s a catastrophic breach of trust with the users relying on you to keep their funds safe.

Ultimately, confidence in shipping comes from comprehension. If you don’t fully understand the code, you don’t really own the feature. Responsible innovation isn’t about rejecting AI; it’s knowing when to use it as an accelerator, and when you need to keep your own hands firmly on the wheel.

In 2025, I joined the RBL team, a dating platform that had been running since 2015. The original goal was simple: improve filtering, fix location-based matching, and assess whether the system could keep scaling.

At the time, the platform had over 170,000 users running on a legacy PHP + MySQL stack. I was hired to add features, but once I dug into the codebase, it became clear the system had hit a hard ceiling.

The “WTF” Moments

We all know that feeling when you open a legacy codebase and realize standard feature requests are going to be nightmares. Two things stood out immediately:

1. Location matching wasn’t real geo-spatial matching
There was no concept of coordinates or radius-based search. Location was inferred by extracting city names from IP addresses using a paid third-party service, then doing string comparisons. If User A was in “Accra” and User B was in “Accra”, they matched. Anything like “people within 50km” was impossible.

2. Extreme over-normalization
The database schema was rigid to the point of hurting read performance. Simple attributes like height weren’t stored as numbers. There was a separate heights table (1ft, 1.2ft, … 8ft) and user profiles referenced it via foreign keys. Fetching a single profile required joins across tables for height, hobbies, education, and more. Reads were slow, and the schema made iteration painful.

At that point, patching felt irresponsible.

The Rewrite

I made the case to stakeholders that this wasn’t a refactor problem. It was a rewrite problem. The new direction:

• Node.js (Express) for better concurrency
• PostgreSQL with PostGIS for proper geospatial queries
• A flatter schema optimized for reads
• Refactored the mobile client to be modern React Native compatible.

I spent about three months rebuilding the system end-to-end.

• Backend: Moved from PHP to Node.js (Express).
• Data: Moved from MySQL to PostgreSQL (flattened schema, enums instead of join tables, implemented proper geospatial indexing with PostGIS).
• Mobile: Moved client from Legacy React Native to modern React Native.

The Migration (The Scary Part)

The platform had 170k active users. I couldn’t flip a switch, shut down PHP, and assume everyone would update their app overnight. So I didn’t.

Instead, I built a dual-write proxy.

This middleware sat in front of both the old and new backends. When a user on the legacy app updated their profile (for example, changing their bio), the proxy would:

1. Validate the request
2. Transform the payload to match the new PostgreSQL schema
3. Send it to the new Node.js backend
4. Transform it again and forward it to the old PHP backend

Both systems stayed in sync, while a separate job backfilled historical data.

A user on the old app could chat with a user on the new React Native app without realizing they were on completely different backends.

Once adoption crossed a safe threshold, I finally shut down the PHP server.

Post-Launch & The 6-Second API Call

After launch, everything looked good… until traffic ramped up.

The “swipe” endpoint started timing out. Some requests took up to 6 seconds.

The cause was straightforward and painful:
I was running the full matching algorithm — geo filtering, compatibility scoring — on-demand every time a user requested a card.

At this scale, that doesn’t fly.

The Fix: Redis + Prefetching

I introduced Redis and changed the model entirely.

Instead of computing matches in real time:

• When a user opens the app, a background job precomputes their next batch of matches
• The results are cached in Redis
• The API simply reads from cache

Response times dropped from seconds to milliseconds.

The Result

Today, the platform:

• Supports 200,000+ users
• Has real radius-based geo filtering
• Uses a schema that doesn’t require 10 joins to read a profile
• Runs on a stack that can actually scale without fear

More importantly, the migration happened without downtime and without breaking the experience for existing users.

If you’ve ever built a checkout flow in Ghana or Nigeria, you know the drill. You integrate Paystack, and it works great. Then a client asks for a specific payment flow that only Flutterwave supports, or you need to expand to East Africa, or you simply want to switch to a new provider that offers better fees.

Suddenly, your clean codebase is littered with if (provider === 'flutterwave') checks. You’re dealing with different response shapes, inconsistent error codes, and three different ways to say “transaction successful.”

I got tired of solving this problem from scratch for every project, so I built Voltax.

I built Voltax to be the “universal adapter” I always wished I had. It’s an open-source, strictly typed SDK that abstracts the chaos of African payment gateways behind a single, unified interface.

Instead of wrestling with documentation for three different providers, you just initialize Voltax, pass your config, and the SDK handles the normalization.

This initial version is built using TypeScript for NodeJS and is live on NPM. I, however, have plans to release versions in Go and Python, etc. You can also submit a pull-request for whatever language or payment gateway you have in mind.

This is my attempt to build the infrastructure I want to see in our ecosystem, and hopefully you can contribute too, and let’s make it work.

Check it out:

• NPM Package
• Documentation
• Github

I wrote my first complete Svelte app last week and have basically been on autopilot since. It’s interesting how a single experiment can redefine your entire development perspective.

My journey with React started back in 2019, and while I’ve built a career on it, moving to Svelte has been surprisingly swift. I was able to grasp the fundamentals and build my first app in less than an hour, a testament to documentation that is truly best-in-class. It smoothed out the learning curve I spent months battling with React.

The developer experience just feels… lighter. Navigating routes doesn’t feel like a heavy chore anymore; the app just snaps into place. Svelte’s syntax feels like native HTML and JavaScript. I’m not inventing new patterns or fighting with className versus class I’m just writing web code. Even state management, which usually requires a complex mental model in React, is handled by Svelte “runes” in a way that just makes sense.

This experience means one thing right now: I’m not just planning future projects in Svelte, I’ve already begun migrating my existing ones, including this portfolio. It’s clear there’s no going back.

Good luck my fellow React devs. Hopefully, you’ll come to see the light.

I’ve been thinking a lot about why some tools just click, while others make me want to shut my laptop and walk away.

You know the feeling. You’re trying to integrate an API, the docs are vague, the error messages are useless, and you’re deep into Stack Overflow just to make a simple request work. That experience sticks with you, and not in a good way.

On the flip side, tools like Stripe, Supabase, and Vercel feel almost… relaxing to use. Things work. The examples actually run. You copy, paste, and suddenly you’re productive. That feeling matters way more than we used to admit.

DevX used to be something teams promised to “improve later.” Now it feels like the product. With APIs everywhere and AI writing more of our code, bad developer experience stands out instantly. If something is painful to use, it’s easier than ever to just switch.

For me, good DevX is pretty simple:
How fast can I get something working?
Do the docs help me when I’m stuck?
Do the errors tell me what I did wrong instead of blaming me?

More and more, the tools that win aren’t the most powerful ones. They’re the ones that make you feel capable while using them.

And honestly, as someone who’s integrated a lot of APIs and fought through a lot of bad docs, I’m really glad this is finally getting the attention it deserves.

I’ve been working in Ghana’s tech scene long enough to see how much has changed and how much we still kind of guess our way through.

We talk a lot about “growth,” fintech, startups, and opportunity, but when it comes down to real numbers, salaries, roles, challenges, who’s building what, we mostly don’t have solid data to point to.

That’s why I’m taking the 2025 Ghana Tech Ecosystem Survey by Code & Cocktails, and why I think it’s worth a few minutes of your time too.

Last year’s survey actually produced useful insights. Not vibes. Real data that helped people understand where the ecosystem stands and sparked better conversations around policy, careers, and investment.

This year only works if enough of us show up. Developers, founders, designers, operators, everyone counts. The survey is anonymous, takes about 10 minutes, and your answers become part of a bigger picture instead of just another Twitter thread.

If you care about the future of tech in Ghana, or you’re simply working in it, this is one small way to contribute.

Ready to make your voice count? Take the survey now at:

https://bit.ly/25TechSurvey

One of the hardest things I had to learn as a freelance developer wasn’t a framework or a language, it was time estimation.

You can be really good at writing code, but if you constantly underestimate how long things take, it catches up with you fast. Missed deadlines, stressed nights, and awkward client conversations… I’ve been there.

After about six years and a couple dozen projects, I’ve learned that timelines almost never slip because of the “hard” coding. They slip because of unclear scope, waiting on feedback, edge cases, and life happening in between.

Now my approach is simple:
I break work into small pieces.
I estimate in hours, not vibes.
I add a buffer, even when I feel confident.
And I’m honest about how much time I actually have.

Clients don’t need perfect estimates. They need realistic ones. I’ve found that communicating progress in milestones builds way more trust than just promising a delivery date and hoping everything goes right.

These days, I’d rather sound a bit conservative upfront and deliver early than be optimistic and explain delays later.

Accuracy beats optimism, every time.