DEV Community: Franklyn Nmesoma

Building Production AI Systems (Part 3)

Franklyn Nmesoma — Fri, 24 Jul 2026 05:45:00 +0000

Running OpenRouter in Production: What Breaks, What Works, and What I’d Do Differently

Getting an LLM to respond to your first prompt is easy.

Keeping it reliable in production?

That’s where things become interesting.

One thing I’ve learned building software is that users don’t care whose fault it is when something breaks.

If your AI feature fails because OpenAI is down…

Or Claude is rate-limited…

Or your network connection decides to disappear for five seconds…

Your users won’t blame the provider.

They’ll blame your application.

That’s why integrating an AI model isn’t enough.

You need to engineer for failure, lets talk about how.

Error handling should be boring

One of the biggest advantages of OpenRouter is that it standardizes responses from different providers.

Without it, you often end up writing provider-specific error handling.

```typescript
if (provider === “openai”) {
…
}

if (provider === “anthropic”) {
…
}

if (provider === “google”) {
…
}
```

That gets messy very quickly.

With OpenRouter, your application talks to one API contract.

Which means your error handling becomes predictable.

```typescript
try {
const response = await client.chat.completions.create({…});
} catch (error) {
logger.error(error);
}
```

Simple.

Your code shouldn’t care which provider failed.

It should care how your application responds when one does.

Logging is your best friend

One mistake I see quite often is developers only logging the error message.

That’s rarely enough.

When something fails in production, you want context.

Log things like:

The model that was used.
Request duration.
Token usage.
HTTP status code.
Whether a fallback model was triggered.
The user making the request (if appropriate).
Timestamp.

A single log entry should tell you the complete story without having to reproduce the issue.

Future you will appreciate it.

Observability beats guessing

Imagine a customer reports:

“The AI stopped working around 2 PM.”

Without observability, you’re guessing.

Was it your backend?

OpenRouter?

Claude?

Gemini?

A timeout?

A deployment?

Good observability removes the guesswork.

OpenRouter provides request tracking that allows you to match requests from your application with what happened inside their dashboard.

Instead of spending hours wondering where things went wrong, you can trace a single request from your backend logs all the way through the gateway.

That’s incredibly valuable once real users are involved.

Request IDs are underrated

Every request should have an identity.

Whether you’re using OpenRouter’s request identifiers or generating your own correlation IDs, always include them in your logs.

Imagine one user reports:

My response never arrived.

Without a request ID, you’re searching through thousands of log entries.

With one, you can immediately trace:

when the request started,
which model processed it,
whether retries occurred,
whether fallbacks were triggered,
and how long everything took.

Production debugging becomes dramatically easier.

Streaming isn’t always as straightforward as it looks

Streaming responses make AI applications feel much faster.

Instead of waiting ten seconds for a complete answer, users start seeing words appear almost immediately.

Great user experience.

But there’s a catch.

Not every provider streams responses in exactly the same way.

Although OpenRouter normalizes much of this behavior, you’ll still want to build frontend parsers that are resilient.

Don’t assume every chunk arrives perfectly.

Don’t assume every event contains text.

Don’t assume the connection won’t terminate unexpectedly.

Your frontend should gracefully handle incomplete streams instead of crashing halfway through a response.

Timeouts are not optional

One of the easiest ways to create a poor user experience is to let requests hang forever.

Sometimes providers are slow.

Sometimes networks are unreliable.

Sometimes things simply break.

Your application should know when to stop waiting.

Set reasonable timeout limits.

If a request takes too long, cancel it.

Your users would rather receive a helpful message after fifteen seconds than stare at an infinite loading spinner.

An application that knows when to give up usually feels faster than one that waits forever.

Graceful degradation

This is one of my favourite engineering principles.

Just because one provider fails doesn’t mean your feature should disappear completely.

Imagine your primary reasoning model becomes unavailable.

Instead of returning:

Something went wrong.

Why not automatically switch to a faster fallback model?

Maybe the answer isn’t quite as detailed.

Maybe it isn’t as creative.

But your user still gets a response.

That’s infinitely better than an error screen.

Graceful degradation isn’t about perfection.

It’s about maintaining functionality when perfection isn’t possible.

Build retries carefully

Retries sound simple.

Until they aren’t.

If a request fails because of a temporary network issue, retrying makes sense.

If it fails because the provider is overloaded, retrying after a short delay might work.

But if the request is invalid?

Retrying it five times won’t magically fix bad input.

A good retry strategy should:

Retry only transient failures.
Use exponential backoff instead of immediate retries.
Set a maximum retry limit.
Log every retry attempt.
Stop retrying when success is unlikely.

Retries should improve reliability.

Not create more traffic.

Final thoughts

One thing AI development has taught me is that choosing the right model is only a small part of building reliable applications.

The real challenge is designing systems that continue working when models slow down, providers become unavailable, or networks become unreliable.

Because eventually…

Something will fail.

The question isn’t whether it happens.

The question is whether your users notice.

If they don’t, you’ve probably built your system well.

Enjoying the series? Let me know in the comments.

Ooh and do not forget to connect with me so you do not miss out on the next parts of the series.

Building Production AI Systems(Part 2)

Franklyn Nmesoma — Wed, 08 Jul 2026 13:15:00 +0000

Integrating OpenRouter into a Real Application

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

In the previous article, I talked about why I stopped juggling multiple AI SDKs and settled on OpenRouter as the abstraction layer between my applications and different LLM providers.

Now comes the fun part.

The actual integration.

If you've ever integrated the OpenAI SDK before, then you'll feel right at home because, surprisingly, not much changes.

And honestly, that's one of my favorite things about OpenRouter.

You don't install another SDK.

You don't learn another API.

You don't rewrite your application.

You simply point your existing client somewhere else.

Step 1: Set up your client

If you're already using the official OpenAI SDK, your client initialization changes very little.

//typescript
import OpenAI from "openai";

const client = new OpenAI({
  apiKey: process.env.OPENROUTER_API_KEY,
  baseURL: "https://openrouter.ai/api/v1",
});

That's it.

Instead of pointing to OpenAI's endpoint, you're pointing to OpenRouter's gateway.

From your application's perspective, nothing else really changes.

And that's exactly the point.

OpenRouter doesn't try to replace the OpenAI API.

It implements it.

Why the Base URL matters

At first glance, changing a single URL doesn't seem like much.

But that one line completely changes what your application is capable of.

Yesterday, your requests could only reach OpenAI.

Today, the same client can talk to Claude, Gemini, Llama, DeepSeek, Mistral, Qwen, and hundreds of other models without installing another dependency.

That's the power of abstraction.

Your application doesn't care where the response comes from.

It only cares that it receives one.

Don't ignore the headers

One thing many developers skip is the optional headers OpenRouter recommends.

//typescript
const client = new OpenAI({
  apiKey: process.env.OPENROUTER_API_KEY,
  baseURL: "https://openrouter.ai/api/v1",
  defaultHeaders: {
    "HTTP-Referer": "https://yourapp.com",
    "X-Title": "My AI Application",
  },
});

These headers aren't required for your application to work.

However, they make a huge difference when you're monitoring usage inside the OpenRouter dashboard.

Think of them as metadata.

Instead of seeing anonymous API traffic, you'll know exactly which application generated which requests.

If you're managing multiple projects, you'll thank yourself later.

Model switching becomes configuration

Here's where OpenRouter really starts to shine.

Normally, switching providers means changing SDKs.

Sometimes it means changing request payloads.

Occasionally it means rewriting parts of your application altogether.

With OpenRouter, switching models is often as simple as changing one string.

//typescript
const completion = await client.chat.completions.create({
  model: process.env.MODEL_NAME,
  messages,
});

Yesterday:

MODEL_NAME=openai/gpt-4o

Today:

MODEL_NAME=anthropic/claude-3.7-sonnet

Tomorrow:

MODEL_NAME=deepseek/deepseek-r1

No deployment.

No new SDK.

No wrapper functions.

Just configuration.

That's a huge win for maintainability.

What actually happens after you send a request?

This is probably the most overlooked part of OpenRouter.

When your application sends a request, it doesn't simply forward the payload.

It interprets it.

Your application sends a standard OpenAI-compatible request.

OpenRouter receives it.

Then it translates that request into whatever format the target provider expects.

Claude has its own conventions.

Gemini has slightly different expectations.

Reasoning models expose different parameters.

OpenRouter smooths over those differences before forwarding the request upstream.

When the provider responds, OpenRouter performs the reverse operation.

It normalizes the response back into the OpenAI format your application already understands.

From your code's perspective, every provider behaves like OpenAI.

That's why your application code stays clean while still supporting multiple providers.

Building for failure

Production systems fail.

Rate limits happen.

Providers experience outages.

Network latency spikes.

The question isn't whether they'll happen.

It's whether your application is prepared when they do.

One of my favorite OpenRouter features is model fallbacks.

Instead of depending on a single provider, you can prioritize multiple models.

//typescript
{
  model: "anthropic/claude-3-opus",
  models: [
    "anthropic/claude-3-opus",
    "google/gemini-pro",
    "meta-llama/llama-3-70b"
  ]
}

Imagine Claude temporarily returns a 429 Too Many Requests.

Without fallbacks?

Your user sees an error.

With fallbacks?

OpenRouter automatically retries using the next available model in your priority list.

Most users won't even notice anything happened.

That's the kind of resilience users expect but rarely appreciate.

Final thoughts

One of the biggest lessons I've learned building AI-powered applications is that your application shouldn't care which model answered the request.

It should care that the request succeeded.

The more your business logic depends on provider-specific behavior, the harder your code becomes to maintain.

OpenRouter flips that relationship.

Providers become interchangeable.

Your application stays consistent.

And as new models continue to emerge almost every week, I think that's an architectural decision that will only become more valuable over time.

If you found this helpful, check out part 1, leave a comment and follow me so you don't miss the next parts of the series, coming soon.

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?

DEV Community: Franklyn Nmesoma

Building Production AI Systems (Part 3)

Error handling should be boring

Logging is your best friend

Observability beats guessing

Graceful degradation

Building Production AI Systems(Part 2)

Integrating OpenRouter into a Real Application

Step 1: Set up your client

Why the Base URL matters

Don't ignore the headers

Model switching becomes configuration

What actually happens after you send a request?

Building for failure

Final thoughts

Building Production AI Systems(Part 1)

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

The fragmented client problem

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

The second reason: developers love over-complicating things.

The third reason nobody talks about: no deployment plan.

Final thoughts

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

So where is the money?

But how does the business know the payment worked?

Why does all of this matter?

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

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