DEV Community: Clinton Agburum

The Difference Between a Working App and a Reliable System

Clinton Agburum — Thu, 21 May 2026 12:23:30 +0000

One thing I’ve noticed in software is that although many apps work, very few are reliable.

An app can work perfectly during testing and still completely fall apart when real users start using it seriously.

That’s because there’s a big difference between building something that functions and building something people can consistently depend on.

These days, it has become easier than ever to build software quickly. AI tools can generate code. Boilerplates exist for almost everything. You can spin up beautiful interfaces in days.

And honestly, that’s impressive.

But software is not truly tested when the developer clicks around locally and everything behaves correctly.

The real test starts when reality enters the picture.

When internet becomes unstable.

When users click the same button five times.

When a payment succeeds but your database update fails.

When a third-party API suddenly stops responding.

When traffic spikes unexpectedly.

When staff members make mistakes.

When users enter terrible data.

That’s usually where the difference between a working app and a reliable system starts to show.

A Working App Is Built for the Happy Path

Most apps are built around ideal conditions.

The user signs up successfully.
The payment goes through.
The API responds quickly.
The internet is stable.
Everything behaves normally.

That’s the happy path.

And to be fair, every product starts there. There’s nothing wrong with that.

The problem is that real life almost never stays on the happy path for long.

Real users behave unpredictably.

Some refresh checkout pages halfway through payments. Some use weak internet. Some click buttons multiple times because they think nothing happened. Some enter wrong data. Some abandon processes midway.

A system that only works under perfect conditions is not reliable yet.

It is simply functional.

Reliability Starts With Asking Uncomfortable Questions

Reliable systems are usually built by people who constantly think about failure.

Not because they are pessimistic.

But because production environments are messy.

They ask questions like:

What happens if the payment provider confirms payment but our server crashes before updating the order?
What happens if WhatsApp delays message delivery?
What if two admins edit the same thing at the same time?
What if the internet drops halfway through a request?
What if this API starts timing out?
What if a queue fails silently?
What if someone uploads corrupted data?

A lot of engineering work is not about making things work.

It’s about making sure things keep working when something goes wrong.

That’s a completely different mindset.

Reliability Is Usually Invisible Work

The funny thing is that users rarely notice reliability.

Nobody tweets:

“Wow. This app handled retries properly.”

Nobody praises your audit logs.

Nobody celebrates your backup strategy.

Nobody posts screenshots of your queue architecture.

But these are the things that quietly keep systems alive.

Reliable systems are full of boring things like:

retries
logging
queues
backups
monitoring
validation
permission structures
fallbacks
rate limits
alerts
recovery processes
idempotency checks

Most of these things are not exciting to build.

But they are the reason companies trust software.

A flashy dashboard might impress users for a few minutes.

A reliable system keeps them for years.

Real Systems Usually Look Simpler Than People Expect

One thing I’ve learned is that some of the most important systems are not visually impressive.

A hospital management platform.
A logistics dashboard.
An audit system.
A tax platform.
An internal operations tool.

Many of them are visually simple.

Because the difficult part is usually not the interface.

The difficult part is consistency.

Can the system preserve data integrity?

Can it recover from failure?

Can it handle operational pressure?

Can multiple teams use it safely?

Can the business trust it during critical moments?

That’s where the real engineering starts.

Users Don’t Care About Your Stack

Developers love talking about stacks.

Laravel. Go. Rust. Node.js. AI-generated code. Microservices.

But most users honestly do not care.

Users care about things like:

“Did my payment go through?”
“Did my booking disappear?”
“Can my staff use this without confusion?”
“Will this system still work tomorrow?”
“Can I trust this platform with my business?”

Reliability creates trust.

And trust is what makes software valuable.

Scaling a System Is More Than Scaling Code

A lot of people think scaling only means handling more traffic.

But reliable systems scale operationally too.

As software grows, you start thinking about:

workflows
approvals
access control
team structure
auditability
support processes
communication flows
recovery procedures

At that point, you are no longer just building an app.

You are building infrastructure people depend on.

And infrastructure requires a very different level of thinking.

The Hard Part of Software Is Not Features

Features are important.

But honestly, building features is often the easiest part.

The harder part is building software that survives reality.

Software that still behaves correctly during stress.

Software that can recover from failure.

Software that users stop worrying about because it has earned their trust over time.

A working app can impress people during a demo.

A reliable system quietly supports businesses for years.

And in the long run, reliability is usually what matters most.

Knowing When WordPress Still Makes Sense in this Age of Vibe Coding

Clinton Agburum — Sun, 03 May 2026 12:01:09 +0000

There’s a quiet stigma around WordPress these days.

Especially now that everyone is building with AI and custom stacks. You see people shipping products from prompts, spinning up full apps in hours, and it starts to feel like if you’re not building everything from scratch, you’re doing something wrong.

But after working across different tools and projects, I’ve found something simple.

WordPress still solves real problems better than we like to admit.

I’ve built systems from scratch. I’ve also used WordPress.

I think it’s important to say this clearly.

I’m a full stack developer. I’ve built APIs, dashboards, internal tools, full systems. Laravel, React, different kinds of setups. Real products that people actually use.

And I’ve also used WordPress.

Not as a fallback. Not because I had no other option. But because sometimes, it was the right tool for the job.

That shift in thinking didn’t happen early. It came from experience.

The pressure to always “build”

Right now, there’s a strong push in our space.

Build from scratch. Use AI. Move fast. Ship something impressive.

And to be fair, AI tools like Claude have made it easier than ever to get something working quickly.

But “working” is not the same as “solid”.

A lot of these builds optimize for speed. Not structure. Not long-term maintenance. Not clarity.

You get something that looks right on the surface. But underneath, things can get messy very quickly. That part doesn’t get talked about enough.

I’ve been there. Built fast. Shipped quickly. Then came back later to fix what “fast” broke.

Not everyone is trying to become a developer

This is something we overlook.

A lot of people building products today are not engineers. They’re founders, business owners, operators. They don’t want to learn how to debug issues or trace through logic.

They just want something that works.

And that’s completely valid.

WordPress quietly supports that reality. It gives people the ability to manage content, update pages, and run their websites without needing a developer for every small change.

That's very useful to a lot of people.

AI still needs real engineering thinking

One thing I’ve noticed with AI-generated code is this.

It looks correct.

But if you don’t understand what it’s doing, you won’t know when it’s wrong.

AI doesn’t take responsibility for the output. You do.

So when something breaks, or behaves in a strange way, or introduces a security issue, you’re the one that has to:

understand the problem
explain it properly
guide the fix
review the output
test everything

That’s real engineering work.

Without that foundation, you’re just stacking guesses on top of guesses.

WordPress is boring. That’s why it works.

A lot of developers avoid WordPress because it doesn’t feel exciting.

It’s not new. It’s not trendy. It doesn’t show off your technical ability.

But that’s exactly why it’s reliable.

WordPress is structured. It has solved a lot of problems already:

content management
user roles
publishing workflows
plugins for common needs

You’re not starting from zero every time. You’re building on something that has been tested over and over again.

There’s value in that.

Security and maintenance are different conversations

This is where things become very practical.

With WordPress, if there’s a security issue, the fix is often straightforward:

update a plugin
update the core
follow known best practices

There’s a large ecosystem and a lot of documentation around it.

With AI-generated systems, it’s different.

If something goes wrong, you need to understand the issue before you can even attempt to fix it. Then you need to guide the AI, review what it gives you, and test it properly.

If you’re not technically sound, that process becomes difficult.

Sometimes very difficult.

Cost matters more than we like to admit

In real-world projects, cost is always part of the decision.

WordPress is:

cheaper to build with
faster to launch
easier to maintain

Custom builds or AI-driven systems can look fast at the beginning, but the cost shows up later in debugging, restructuring, and ongoing technical oversight.

WordPress is not glamorous. But it is cost-effective.

And in most real situations, that matters.

Not every problem needs a custom build

There was a time I wanted to build everything myself.

It felt like the right thing to do. Like that’s what made you a serious developer.

But over time, that thinking changes.

Now, I care more about solving the problem well than proving I can build everything from scratch.

Sometimes the right solution is a custom system.

Sometimes it’s WordPress.

Knowing the difference is where experience shows.

The real world rewards what works

At the end of the day, most clients don’t care what stack you used.

They care that:

the site works
it’s stable
it’s easy to update
it doesn’t break often

The real world is not impressed by complexity. It rewards reliability.

Conclusion

These days, I don’t chase tools.

I don’t pick stacks based on what’s trending.

I look at the problem, the constraints, and what will actually work long term.

Sometimes that means building from scratch.

Sometimes it means using WordPress.

Both are valid.

What matters is not how you built it.

What matters is that it works, and it lasts.

Why Idempotency Matters More Than You Think

Clinton Agburum — Tue, 28 Apr 2026 10:44:01 +0000

There’s this kind of bug that doesn’t show up when you’re building.

Everything works.

You click once. It works.
You test your API. It works.
You move on.

Then real users start using it.

Someone clicks “Pay” twice because your page is taking time.
Network glitches and your request gets retried.
A webhook comes in again because you didn’t respond properly the first time.

Now you’re looking at your system like… what just happened?

Two payments.
Duplicate records.
Things just feel… off.

Nothing crashed. But you know something is wrong.

So what is idempotency?

Nothing fancy.

It just means this:

If the same action happens multiple times, the result should still be the same.

Create order → called 3 times → still 1 order
Charge user → called again → still 1 charge

That’s it.

Where most of us get it wrong

When you’re building, you’re thinking:

user will click once
request will go once
job will run once

That’s how we all think at first.

But that’s not how real systems behave.

Browsers retry.
Mobile networks mess up requests.
Background jobs fail and run again.
Payment providers send the same webhook more than once.

Even Stripe literally expects you to handle duplicates. That should already tell you everything.

So the real question is not “will this happen twice?”

It’s “when it happens twice, what does my system do?”

Where this will bite you

Let’s not even overthink it.

Payments

This one is painful.

User clicks twice or request retries → you charge twice.

Now you’re explaining to someone why they were debited two times for something they bought once.

Not fun.

Forms

A Simple form.

User submits twice → you now have duplicate data.

Sometimes you won’t even notice until later.

Webhooks

If you’ve worked with Paystack or anything similar, you already know.

They will send that event again.

If your system treats it like something new every time, you’ll mess up your own data.

Background jobs

This one is sneaky.

Job fails halfway → retries.

If your logic is not careful, it doesn’t “continue”. It repeats.

Now your data is mixed. Some things done twice, some halfway. Good luck debugging that.

The annoying part

These bugs don’t shout.

No big error. No crash.

Just small weird things:

numbers don’t match
users complain randomly
you can’t reproduce it

And you start saying things like:

“it’s working on my side”

Meanwhile, something is clearly wrong.

What actually helps

You don’t need to overcomplicate it.

Just think ahead a bit.

Idempotency keys

For things like payments, send a unique key.

If that same key comes again, don’t process it again. Just return the previous result.

Database constraints

If duplicates should not exist, enforce it at the database level.

Not just “hope your code handles it”.

Check before doing

Before you process something, check:

“has this already been done?”

If yes, stop there.

Assume things will repeat

This mindset alone changes how you build.

Don’t build like things happen once.

Build like things can happen again at any time.

Idempotency is one of those quiet things that makes your system solid.

Conclusion

If your system breaks because the same request happens twice, then it’s not ready.

Simple as that.

Most people only learn this after something goes wrong.

Better to think about it early.

Building for Real Users vs Building for Demos

Clinton Agburum — Mon, 20 Apr 2026 21:17:43 +0000

Most products don’t fail because the idea is bad.
They fail because they were never built for real users.

They were built for demos.

What a demo looks like

A demo is controlled.

You open your app.
You click through a smooth flow.
Everything works.

You feel good.

But that’s because nothing went wrong.

The internet was fast
The inputs were correct
The steps were followed in order
No one did anything unexpected

You basically designed the experience and the user just followed it.

The problem

Real users don’t behave like that.

They don’t follow your script.

Many things can go wrong.

What real users actually do

Someone opens your app.

They enter the wrong email
They use a bad phone number
They refresh halfway
They leave and come back later
They click things out of order
Their network goes off

Now your system has to deal with that.

Simple example

You build a form.

In your demo:

User fills everything correctly
Clicks submit
Sees success message

Done.

In real life:

User fills half the form
Leaves
Comes back later
Changes one field
Clicks submit twice because nothing happened
Network fails the first time

Now you have:

Duplicate submissions
Incomplete data
Confused user

If your system breaks here, then what you built was just a demo.

Another example

You build an RSVP system.

In your demo:

1 person responds
Clean data
Everything looks perfect

In real life:

300 people respond at once
Some enter wrong numbers
Some submit twice
Some change their mind
Some don’t respond at all

Now your system has to:

Handle duplicates
Track updates
Stay fast under load

That is the real test. I saw this firsthand while building Invyt, where real user behavior quickly exposed things that worked fine in testing.

The wrong assumption

When building demos, many people assume:

Users will follow the flow
Data will be clean
The network will work
Errors are rare

None of this is true.

The right mindset

When building a real product, assume this instead:

Users will break your flow
Data will be messy
The network will fail
People will do things you didn’t plan for

So you build for that.

What changes when you think this way

You stop asking:

“Does it work?”

You start asking:

“What happens when this goes wrong?”

What if they submit twice
What if the request fails
What if they leave halfway
What if 100 people do this at once

That’s where you'll begin to get it right.

The hidden cost of demos

The truth is that if you only build for demos:

Bugs show up in production
You keep patching things
Users lose trust
Your team gets frustrated

Because the product was never ready for real users.
A product is not tested when everything works.
It is tested when things go wrong.

Quick Check: Is Your Product Ready for Real Users?

Before you call it done, run through this:

Can it handle bad input? What happens if a user enters the wrong data? Do you validate and guide them, or does it just break?
What happens if the network fails? Does the action retry? Does the user get feedback, or are they left guessing?
Can users recover from mistakes? Can they go back and fix things? Or do they have to start all over again?
What if they don’t finish the flow? Is progress saved? Can they return and continue later?
Can it handle repeated actions? What if they click submit twice? Do you prevent duplicates?
What happens under pressure? If many users use it at once, does it still work? Or does it slow down and fail?
Are errors clear and helpful? Do users understand what went wrong? Do they know what to do next?
Can you see what’s going on? Are errors logged? Can you track issues when users report them?
Does it work outside your setup? Different devices Different browsers Slower connections
Can you support it after launch? If something breaks, can you fix it quickly? Or are you blind once it’s live?

Final thought

If your product only works when everything goes right,
it’s not a product.

It’s just a demo.