DEV Community: Amon Ochuka

The Rise, Pause, and Rise of CRUD Apps

Amon Ochuka — Wed, 27 May 2026 07:19:46 +0000

In the early days of the web, websites were mostly digital brochures. They were static HTML pages. You could read them, but you couldn't interact with them. If a business wanted to change a price, a developer had to manually edit code and re-upload the file via FTP.
It was slow, expensive, and didn't scale.

Then came the legendary LAMP stack (Linux, Apache, MySQL, PHP). Suddenly, the web became dynamic. The industry quickly realized that almost every business problem on earth;whether running a bank, an online store, or a social network,boiled down to four fundamental actions:

Create: Letting a user sign up or post a status.
Read: Showing a user their profile or a product list.
Update: Letting a user change their password.
Delete: Letting a user close an account.

By the mid-2000s, frameworks like Ruby on Rails, Django, and Laravel arrived. They turned CRUD into a science. With a single command line prompt (rails generate scaffold), a developer could spin up a fully functioning database table, back-end logic, and front-end forms in seconds.
This was the first great rise. CRUD apps became the undisputed infrastructure of the global economy. They weren't flashy, but they were predictable and deeply tied to the absolute truth of the database.

The Pause: The "CRUD is Boring" Mirage
Then, things got weird. Around 2015, the developer community collectively decided that simple, server-rendered CRUD apps were "boring." We entered the era of massive Single Page Applications (SPAs), microservices, GraphQL, and serverless hype.We started treating the database like something to be hidden behind ten layers of abstraction. Instead of a simple PHP or Rails script fetching a row from MySQL, we introduced a mountain of complexity:

The SPA Takeover: We moved the entire application logic to the browser. Suddenly, a simple user profile required React, Redux for state management, Webpack for bundling, and a massive JavaScript file that took 5 seconds to load on a mobile phone.
The API Chasm: We separated the front end and the back end entirely. Now, to display a simple list of products, you needed a REST or GraphQL API layer, complex CORS configurations, and token-based authentication (JWT) just to talk to your own database.
Microservice Madness: We broke monolithic apps into dozens of tiny services. A basic update operation now had to hop across three different servers, manage distributed transactions, and use Kafka queues just to change a user's email address.

We spent a decade over-engineering the front end just to realize that users still just want to fill out a form and hit submit. We swapped reliable server logs for confusing JavaScript console errors. We paused the simplicity of CRUD, and in return, we got total JavaScript fatigue.

The Crypto & Blockchain Detour: An Append-Only Trap
As the web-development world was over-engineering the front end, the Web3 and blockchain movement emerged, promising to decentralize the entire internet. Enthusiasts claimed that the "shared ledger" would replace traditional databases entirely.

But reality caught up quickly.

A blockchain is fundamentally an append-only ledger. In CRUD terms, it is brilliant at Create and Read, but terrible at Update and Delete.

Because data on a blockchain is immutable, it is incredibly slow and quite expensive for everyday operations. Worse, it creates a massive legal nightmare. Privacy frameworks like Europe's GDPR mandate that users have the "right to be forgotten"; a legal requirement to Delete data. Because you cannot delete data from a block, tech companies quickly realized they couldn't run a compliant business on a blockchain alone.

The blockchain didn't kill the database; instead, decentralized applications (dApps) still had to be wrapped in traditional CRUD architectures to cache data, update states quickly, and manage local user profiles efficiently.

The Second Rise: AI and the Return to Absolute Truth
Following the blockchain hype came the AI boom. Large Language Models (LLMs) can write code, analyze data, and build entire workflows in seconds. Prominent tech voices started declaring that apps were dead, and the era of the user interface was over.

But once again, the industry hit the same foundational wall: AI is probabilistic, but business is deterministic.

AI can write poetry, but it still needs a SQL database to know where to ship your package. An LLM cannot guess a bank balance. It cannot "predict" a shipping address. AI models are stateless; they don't know anything for sure; they just guess the next most likely word based on probability.

Tech is the User, CRUD is the Foundation
This realization has triggered the second rise of the CRUD app. We aren't throwing CRUD away; we are realizing it is the guardrail that keeps both AI and Web3 tethered to reality.
The relationship has completely flipped: AI and blockchain are no longer trying to replace the CRUD app; they are becoming the users of it.

When an AI agent "cancels your subscription," it executes a standard Update or Delete command via a regular API to a traditional database.

When a smart contract processes a transaction, a traditional CRUD system reads the event to update a user's dashboard instantly.

The Ultimate Backup
Most importantly, CRUD apps are our absolute fallback. AI models hallucinate, prompt injections corrupt logic, and decentralized networks suffer from latency or high gas fees.
When the advanced tech stack glitches or goes offline, humans cannot be left staring at a broken terminal. We need a direct, unabstracted, deterministic interface to view, edit, and fix the underlying data manually.

We need a CRUD app as our ultimate backup.

Conclusion: Boring is Beautiful Again
The tech industry went on a decade-long detour. We ran away from CRUD because it felt too simple, hiding it behind over-engineered JavaScript frameworks, distributed ledgers, and autonomous AI.

But the loop has closed. We are entering an era where "boring" software is beautiful again. Frameworks like Next.js, Remix, and HTMX are booming because they bring us back to simple, server-rendered data management.

No matter how smart the AI gets or how decentralized the ledger becomes, the world will always need a rock-solid database to store the absolute truth. And humans will always need a CRUD app to make sure that the database is backed up.

Long live the CRUD app.

Kiboko to Sherehe(polite): From Strict Go Rules to JavaScript Chaos

Amon Ochuka — Thu, 07 May 2026 17:53:56 +0000

Growing up in a typical strict African household always had a very clear structure, well at least for me.
There were rules. Not suggestions. Not “best practices.” Rules. You never really negotiated them, you just executed them.

You woke up early. You went to school. You came back on time. You didn’t always get the chance to “try things.” You mostly followed instructions.

If you messed up, there was usually a very immediate feedback loop.
Let’s just call it… real-time debugging. ("Kiboko")

Now fast forward to adulthood (or campus life, which feels like a soft launch into adulthood).
Suddenly:

No one is asking where you are
You can sleep at 3AM and call it “freedom”
Food is no longer provided;it’s a budgeting problem
And somehow, people are going out on weekdays like it’s normal("sherehe polite")

It feels like moving from a tightly controlled environment into an open-world sandbox with no manual.

And that’s exactly how learning JavaScript felt after coming from Go.

Go felt like home

Go is structured, strict, and predictable.It feels like that kind of upbringing where:

There is a correct way to do things
Mistakes are immediately pointed out
You don’t get “creative freedom” with rules
Everything has a clear, disciplined path

If you write something wrong, Go doesn’t argue with you.
It simply refuses to proceed.
Very “strict parent energy.”

JavaScript feels like campus life

Suddenly, everything is allowed.
Almost too allowed.

You can write things that technically work but feel emotionally wrong:

"5" + 1 // "51"
"5" - 1 // 4

And the language just… accepts it.
No questions. No intervention. No moral guidance.(This is where I would have been properly debugged)

Coming from Go, it feels like moving from mama's hot home-cooked meals, to a hostel where someone is boiling noodles in a sufuria at 2AM, while watching YouTube at full volume.

It works.But you’re not always sure it should.

The adjustment phase

At first, JavaScript feels messy.
Too flexible. Too forgiving. Too many ways to do the same thing.
But slowly, something changes.
You realize the language isn’t enforcing discipline on you, you’re expected to build it yourself.

That’s the shift.Go gives you structure upfront.
JavaScript forces you to learn structure through experience.

One is guided discipline.The other is learned discipline

Final thoughts

Growing up strict teaches you order.Campus life teaches you independence.
Go gives you rules.
JavaScript gives you freedom, and occasionally lets you suffer for bad decisions.

And maybe that’s the real lesson:
Structure is important, but so is learning how to create it for yourself when no one is watching.

Why AI Is Unlikely To Be A Game-Changer In African Economies

Amon Ochuka — Tue, 17 Feb 2026 07:34:27 +0000

Everyone is talking about AI transforming Africa, but the reality on the ground is very different, especially in countries facing electricity shortages and monopolies in key sectors. While AI has enormous potential globally, in many African contexts it is unlikely to become the economic miracle some people hope for, at least in the near term.

Electricity Shortages Are a Major Bottleneck

AI systems, whether cloud-hosted or on-device, consume a significant amount of electricity. Training even a single large AI model can use as much power as a small town in a month. Many African countries struggle with unreliable grids and frequent load shedding. Even highly skilled developers cannot run AI consistently without stable electricity, and relying on generators or solar power adds both cost and operational complexity, making many AI projects financially unviable.

Infrastructure Needs Go Beyond Power

AI requires more than electricity. Fast internet, reliable data storage, cloud computing, and ongoing maintenance are essential. Many regions still lack basic connectivity, and data centers are often concentrated in a few major cities. This makes AI adoption uneven and prevents smaller startups from scaling their solutions effectively.

Monopolies Stifle Innovation

Key sectors like telecommunications, banking, and energy are dominated by a few large players. Small AI startups often struggle to access APIs or market opportunities, as monopolies prioritize existing profit models over risky new technologies.

Talent Gaps Limit Scale

AI requires skilled engineers and data scientists. While Africa has a growing developer community, high-level AI talent remains limited, and access to training and compute resources is uneven, slowing adoption.

Localized Opportunities Exist

AI can succeed where infrastructure is reliable, such as mobile money in Kenya or agri-tech in parts of Nigeria. These are notable exceptions, not the rule.

Conclusion

AI is a powerful tool, but tools don’t operate in a vacuum. Without reliable electricity, fair competition, and solid infrastructure, AI is unlikely to drive broad economic growth. Prioritizing fundamental challenges should come first, before expecting AI to revolutionize economies.