DEV Community: Franklyn Nmesoma

Building Production AI Systems(Part 1)

Franklyn Nmesoma — Sat, 04 Jul 2026 13:15:00 +0000

OpenRouter isn't just another AI gateway. It's an architectural decision.

This is Part 1 of a five-part series on building production-ready AI applications.

A few months ago, if you wanted to experiment with multiple LLM providers in the same application, you'd probably end up with something like this:

npm install openai
npm install @anthropic-ai/sdk
npm install @google/generative-ai

Fast forward a few weeks and your code-base starts looking… interesting.

One SDK expects messages in one format.

Another throws completely different error objects.

One provider supports streaming differently.

Another requires its own authentication flow.

Before long, you've written a wrapper around a wrapper that's wrapping yet another SDK just so your application can ask a chat-bot a simple question.

I've been there.

And honestly, none of that complexity adds value to your product.

Your users don't care whether the response came from GPT-4o, Claude Sonnet, Gemini, DeepSeek, or Llama.

They care that the response is fast, reliable, and useful.

That's what eventually led me to OpenRouter.

At first, I assumed it was just another API gateway sitting between my application and a bunch of AI providers.

After using it in production, I realized it solves a much bigger problem.

It lets you stop thinking about providers and start thinking about capabilities.

The fragmented client problem

One of the biggest mistakes teams make when integrating AI is tightly coupling their application to a single provider.

It usually starts innocently.

Maybe you're building with OpenAI because it's the easiest place to begin.

A few months later, Claude becomes better at long-form reasoning.

Then Gemini introduces a feature you want.

Then an open-weight model suddenly becomes good enough while costing a fraction of the price.

Now you have a problem.

Your application isn't talking to "an LLM."

It's talking to three completely different SDKs.

Three authentication methods.

Three different request formats.

Three different response objects.

Three different ways of handling errors.

Suddenly, changing models isn't a product decision anymore.

It's a refactoring exercise.

That's exactly the problem OpenRouter solves.

Instead of installing a separate SDK for every provider, OpenRouter becomes a single entry point for every model your application needs.

To your application, it behaves like the OpenAI API.

To your infrastructure, it's an orchestration layer capable of routing requests to hundreds of proprietary and open-weight models.

That distinction matters.

Because now your code isn't coupled to Anthropic.

Or Google.

Or OpenAI.

It's coupled to one API contract.

Everything else becomes configuration.

And in software engineering, configuration almost always ages better than code.

That was the first thing that stood out to me.

OpenRouter isn't really selling access to models.

It's selling abstraction.

And good abstractions are usually what make systems maintainable in the long run.

If you found this helpful, leave a comment and follow me so you don't miss Part 2 of the series, coming soon.

# Side projects don't fail because of bad code. They fail because...

Franklyn Nmesoma — Wed, 24 Jun 2026 14:15:00 +0000

It's crazy how nobody really talks about this.

An idea pops into your head. You validate it. Maybe a few people tell you it's a good idea. Next thing you know, you're three weeks deep into building the next X (formerly Twitter).

There's just one small problem:

You're not building for users. You're building for yourself.

The way developers see products is completely different from the way users see them.

A developer sees pixels, color gradients, load times, request speeds, database queries, security, and architecture.

The user sees one thing:

An app.

That's it.

Most users don't care that your font size is off by 2px. They don't care whether you're using React, Vue, Laravel, Next.js, PostgreSQL, MongoDB, or whatever new framework launched last week.

What they care about is simple:

Can I use this thing without getting frustrated?

That's the real question.

Think about the products you use every day. Why do they have millions of users?

It isn't because the UI is beautiful.

It isn't because the architecture is perfect.

It's because they're usable.

Can users understand your product without watching a tutorial?

Can they complete important actions without getting confused?

Can they find what they're looking for without clicking through five different screens?

If the answer is no, then you don't have a technical problem.

You have a product problem.

And product problems kill side projects much faster than technical ones.

The second reason: developers love over-complicating things.

A lot of developers struggle with this, especially when building side projects.

A simple note-taking application somehow becomes:

AI-powered
Real-time
Multi-tenant
Offline-first
Blockchain-enabled

All before a single user has written their first note.

A notes app doesn't need AI.

It needs to let users:

Create notes
Save notes
View notes
Delete notes

That's it.

There's a difference between building the right thing and just building things.

The hack?

KISS.

Keep It Simple, Stupid.

(Or Keep It Short and Simple if you're feeling polite.)

The principle is the same.

Your application should perform its primary task exceptionally well before you start adding features nobody asked for.

The more complexity you introduce, the more opportunities you create for things to break.

Build with KISS in mind and thank me later.

The third reason nobody talks about: no deployment plan.

This one hurts.

You spend months building.

Next.js for the frontend.

Laravel for the backend.

PostgreSQL for the database.

Redis for caching.

Docker because everyone on YouTube says you should learn Docker.

Everything sounds cool until it's time to deploy.

Now you're trying to figure out hosting, environment variables, SSL certificates, databases, storage, monitoring, backups, and why your frontend suddenly can't talk to your backend.

This is where many side projects quietly die.

Not because the code was bad.

Because nobody thought about operations.

Before writing your first line of code, ask yourself:

How is this thing actually going to run?

How will the services communicate?

How will updates be deployed?

How will users access it?

How will I keep it online when something breaks?

Your goal isn't to build something that works on your machine.

Your goal is to build something users can depend on.

Those are two very different things.

Final thoughts

Most side projects don't die because of bad code.

They die because nobody wanted to use them.

They die because they're overengineered.

They die because the developer spent more time choosing technologies than understanding users.

And sometimes they die because nobody thought about what happens after the code is finished.

The irony is that writing the code is often the easiest part.

Building something people actually use?

That's the hard part.

What actually happens between you pressing Pay and the money moving?

Franklyn Nmesoma — Wed, 17 Jun 2026 06:15:00 +0000

You buy something online. You enter your card details, tap PAY, and within seconds you see:

Payment Successful.

Simple enough, right?

However, here's the interesting part:

The money hasn't actually reached the business owner yet.

I know. Sounds strange.

After all, if your account has already been debited and the website says payment was successful, shouldn't the merchant have the money immediately?

Not exactly.

To understand what really happens, let's introduce the key characters involved in this transaction.

You – the customer making the payment.
The vendor – the business selling the product or service.
The payment processor – Paystack, Stripe, Flutterwave, Remita, etc.
Your bank – the institution holding your money.
The merchant's bank – where the business eventually receives its funds.

Now, let's follow the journey of your money.

## What happens after you click Pay?

The process begins almost immediately after you hit that button.

First, the payment processor receives your payment request. Think of it as the middleman coordinating the entire process.

The processor then contacts your bank and essentially asks:

"This customer is trying to spend ₦10,000. Do they have enough money, and should this transaction be approved?"

Your bank checks a few things:

Is the card valid?
Is there enough money in the account?
Has the card been blocked?
Does anything about this transaction look suspicious?

Based on these checks, your bank sends back one of two responses:

Approved
Declined

If the payment is declined, the transaction stops there.

If it's approved, the payment processor immediately notifies the business that the payment was successful.

This is usually when you receive that reassuring message:

Payment Successful.

But remember:

The merchant still hasn't received the money.

So where is the money?

This is where many people get confused.

That "Payment Successful" message doesn't mean your money has been instantly teleported from your account into the merchant's account.

What has happened is that the transaction has been authorized.

The actual transfer of funds happens later through a process known as settlement.

Settlement is simply the process of moving the approved funds to the merchant's bank account.

Depending on the payment processor, settlement can happen:

Later that same day,
The next business day,
Or according to a predefined settlement schedule.

This means there is often a time gap between:

"The customer has paid."

and

_"The business has received the money."
_

But how does the business know the payment worked?

Imagine ordering food online.

You've paid.

The restaurant needs to know whether to start preparing your order.

This is where something called a webhook comes in.

Now, don't let the technical name scare you.

A webhook is simply an automated message sent from the payment processor to the business saying:

"Hey, that payment went through. You can go ahead with the order."

Without this notification system, businesses would have to manually check every single payment before processing orders.

Webhooks make the entire experience feel instant, even though multiple systems are communicating behind the scenes.

Why does all of this matter?

Because most of us interact with payment systems every single day without ever thinking about what happens in the background.

We pay for groceries.

We buy movie tickets.

We renew subscriptions.

We transfer money.

All in a matter of seconds.

But behind that tiny Pay button is an entire network of banks, payment processors, security checks, notifications, and settlement systems working together to make the experience seamless.

The next time you see:

Payment Successful

you'll know that it's not the end of the journey.

It's simply the moment everyone involved agrees:

"Yes, this payment is valid. Let's continue moving the money where it needs to go."

And somewhere in the background, a very busy orchestra of systems is making sure that happens without you ever noticing.

React isn't the problem. How we teach it is.

Franklyn Nmesoma — Mon, 15 Jun 2026 06:15:00 +0000

Ask a junior developer to explain what happens after a submit button is clicked. Most can't give a clear answer. For those who can, you'll probably hear something like:

"An API call is made to the back-end server and a response is returned."

Fair enough.

But probe a little further. Ask how the browser packages that request. Ask what HTTP method is being used. Ask where authentication comes into play. Ask how the server processes the request before the data ends up in a database.

That's usually where the silence begins.

This isn't because junior developers are lazy or incapable. We are not producing bad developers. We are producing developers with missing context.

Somewhere along the way, we've started teaching abstractions before foundations.

Many boot-camps and online tutorials optimize for outcomes. The promise is simple: build a portfolio, get job-ready, land your first role. React fits perfectly into that narrative because the results are immediate. You can build something impressive very quickly.

The problem is that many learners are introduced to frameworks before they understand the systems those frameworks abstract away.

They learn React before HTTP.

Components before servers.

State management before databases.

Authentication libraries before authentication itself.

And while there's nothing inherently wrong with React, teaching it too early often creates developers who know what to do, but not necessarily why they're doing it.

The consequences usually show up later.

Many developers fall into what is commonly called "tutorial hell", following along with project videos, copying code line by line, and feeling productive until it's time to build something independently. Suddenly, the confidence disappears because understanding was mistaken for familiarity.

The same concern exists with AI-assisted development.

To be clear, I'm not against AI. I use it regularly. Tools like ChatGPT, Claude, and Codex can significantly improve productivity. The issue arises when they replace thinking instead of supporting it.

Debugging used to force developers into uncomfortable situations. You had to read documentation, search for solutions, experiment, fail repeatedly, and eventually understand the root cause of a problem. That struggle wasn't wasted effort; it was training.

If every obstacle is immediately outsourced to an AI assistant, we risk skipping the very experiences that develop engineering judgment.

This is especially concerning because software development isn't just about producing working code. As developers grow, they are expected to make decisions, evaluate trade-offs, anticipate failure points, and understand the implications of the systems they build.

That level of competence isn't developed through prompting alone.

If I were designing a web development curriculum, this is the order I'd teach things:

HTML/CSS
JavaScript fundamentals
Browser fundamentals
HTTP and APIs
Basic back-end concepts
Databases
Authentication and authorization
Then React

By the time students reach React, they wouldn't just know how to use useEffect; they would understand why data fetching exists in the first place. They wouldn't just know how to submit forms; they would understand what happens after the submit button is clicked.

React isn't the problem.

AI isn't the problem.

The problem is that we're moving people through the foundations too quickly and expecting the gaps to fill themselves over time.

Sometimes they do.

Often, they don't.

So I'll end with this question:

Are we gatekeeping, or are we teaching the next generation of developers to build without truly understanding what they're building?