DEV Community: Clinton Agburum

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.