
On why people would rather burn millions on over-engineered trends than admit they only need a simple solution. From Beirut internet cafes to Kubernetes clusters serving forty users.
He threw the envelope at my face.
I had walked into a small petrol station to pitch a web development contract, holding a clean, highly functional, cost-effective quote built on top of a WordPress foundation. The owner did not look at the proposal. He looked at the envelope, looked up at me, and said: "WordPress? Who the fuck you think you are?"
This is what the cult of complexity looks like up close. A man who has never written a line of code in his life, deeply offended that I was not going to hand-carve his website from raw silicon. Years later I would meet the same instinct in boardrooms, in cloud architecture reviews, in AI product demos. The accent changes. The vanity does not.
The Nicotine-Stained PC
To see this blueprint in its purest form, look at Lebanon in 1998. I was ten years old when I first heard about an internet cafe, because one had a massive sign outside for FIFA: Road to World Cup 98, the EA Sports game with Chumbawamba's "Tubthumping" blasting on the menu screen on loop. The line was so long it would have been faster to fly to France and watch the actual tournament live. Internet cafes became a massive trend overnight, considered "easy money," and every entrepreneur on every corner opened one. Within a few years, what started as a row of shiny gaming PCs had rotted into a bleak room of off-white monitors stained with cigarette smoke, game libraries as empty as the cafes themselves. Nobody paused to ask if the market actually needed another one. They saw a trend and sprinted toward it blindly until it decayed from the inside out.
🔄 The Trend Decay Loop
Every iteration of this pattern runs the same cycle: a new technology generates massive early returns, the herd rushes in, supply saturates the market, prices collapse, quality collapses with them, and the trend rots from the inside out. Internet cafes. Bespoke custom CMS platforms. Over-engineered cloud stacks. AI chatbot wrappers. The loop never changes. Only the acronyms do.
The Stigma of "Ready-Made"
This obsession with building things yourself rather than using standard tools is driven by a profound, almost aggressive cultural stigma against anything "ready-made." It is woven into every layer of daily life in the Levant. You see it on Christmas Eve, when your grandma is huffing and puffing in total disapproval because your mom made the practical decision to buy a ready-made turkey rather than slaughtering and preparing one entirely by hand. You see it in old-school classrooms where teachers reject the very concept of a calculator because "everything must be calculated by hand."
We have a beautiful old proverb that translates to: "Give your bread to the baker, even if he eats half of it." It means you should leave specialized tasks to the professionals. But the tragedy of our culture is that everyone honestly thinks they are the master baker. You should see the look people give you when you tell them you are hiring a plumber. The immediate reaction is hubris: "Why pay them? I can do it better myself."
Local mechanics will genuinely convince themselves that they know better than the engineers at multi-billion-dollar German automotive laboratories. I remember a friend of mine whose dad bought a brand-new Mercedes S-Class. It needed a simple, routine oil change. Instead of taking it to the official dealership service center, he made the mistake of taking it to a neighborhood garage.
When the mechanic handed the car back, he also handed over a small pile of four extra screws and a couple of detached sensors. The guy looked him dead in the eye, winked, and said: "Listen, habibi, you don't need these. Mercedes only adds these extra parts to drive up the price of the car." He honestly believed he had out-engineered Stuttgart in a garage in Beirut.
"WordPress? You Think We Are Poor?"
When the web boom finally hit the region, that exact same "four extra screws" mentality shifted straight into code. It became culturally 3ayb (shameful) to buy or use a ready-made website layout or platform. If you used a pre-built framework, you were considered poor, uneducated, or lazy. You had to build it yourself from scratch to save face.
The fallout of this mindset is a quiet disaster. The reality is that while our people are historically fantastic at cooking or physical car mechanics, the region was late to the web engineering trend, but everyone wanted to act like an elite software architect anyway.
A production server is not a traditional cook. You can't just burn a dish, throw it in the trash, and start over. But these proud business owners refused to use established, standard platforms, so they gave their contracts to cheap, corner-cutting development companies who promised them a "custom, built-from-scratch" website.
Under the hood, these custom websites were mechanical disasters. A bored teenager could SQL inject them in thirty seconds. They completely lacked basic security protocols, proper caching layers, and structural data validation. Those cheap agencies threw away all the "extra screws and sensors" that actually keep an enterprise safe, exposing customers' names, addresses, and raw credit card data to anyone who asked. And when the database inevitably got breached or the server crashed under a minor traffic spike, the owner never blamed their own vanity or the cheap agency that ripped them off. They blamed the internal developer, the one who spent months trying to convince them to use WordPress or Shopify, only to be laughed out of the room and told it was 3ayb.
Same Vanity, New Acronyms
The instinct does not stop at the application layer. It mutates straight into cloud infrastructure, and in Developer Experience, you spend a surprising amount of your career cleaning up after it.
I have been pulled into more than one architecture review where a team is drowning in deployment friction and YAML files that nobody fully understands anymore. One of them I still remember: the lead architect walked me through a service-mesh diagram the size of a subway map, leaned back, and said, with the exact same wink as that Beirut mechanic, "We're building for scale." When you trace these decisions back, the origin is always the same: someone read an engineering whitepaper from Netflix or Google, decided that a plain virtual private server was beneath their dignity, and convinced leadership they needed a bespoke spaceship. AWS EKS, Kubernetes, Docker registries, distributed service meshes, multi-zone RDS replication. The full stack. For a shop that takes forty orders on a good day.
They burned thousands of dollars a month in compute costs while their developers drowned in the maintenance overhead. The same people who refused to use WordPress because it was 3ayb just signed off on an architecture three orders of magnitude more complex, because it was custom-built and had the right acronyms in the slide deck. The wink holds right up until the client sees the first cloud bill. Then the panic starts, and everyone suddenly wants to know why a small online shop costs more every month than a year of plain shared hosting.
And the bill is never the end of it, because in tech every layer breeds the next. Every service you spin up now needs observability, so you bolt on metrics, traces, and dashboards. Observability is only worth anything if it tells you the moment something breaks, so you wire up alerting. Alerts that fire at three in the morning need a human awake to catch them, so now you are funding an on-call rotation. And the company stipend is the cheap part. When that Grafana alert goes off, it does not wake one engineer. It wakes his wife and his sleeping infant too, because the alarm is loud enough to rattle the whole building. I know, because mine once sat up in the dark and said, "Stop it. I will pay you the thirty euros for on-call myself, just let us sleep." And the best part? The alert was not even real. It was a demo service some engineer had spun up weeks earlier and forgotten to tear down, stuck in a crash loop on the dev cluster, paging the whole rotation over absolutely nothing.
Each layer is a perfectly reasonable answer to the layer beneath it, and not one of them would exist if you had just shipped the boring thing. Complexity does not add up. It compounds.
The Real Bill
The worst line on the bill is never the money. It is the human cost. A new engineer now has to wade through thousands of lines spread across a dozen microservices just to move a button. Every change drags a tail behind it: a review, a sign-off, a round of QA, a deploy window measured in coffee breaks. Worse, the services are so entangled that you cannot touch one without updating another, so the simple fix gets parked until next sprint. Next sprint it turns out to depend on a third service, so it gets parked again. And again. The work does not get cancelled. It quietly dies in the backlog while everyone stays busy.
And none of it does a single meaningful thing for the client who trusted you with a simple website, the one who just wanted to earn a little more. Whatever revenue it brings bleeds straight back into the machine, feeding the same complexity that is starving the business it was built to grow.
Now the Machine Talks Back
The current mutation runs on large language models.
You open a banking app to check your balance and get trapped in a conversation with a sluggish chatbot asking about your financial goals. You open a food delivery app and instead of a clean, instant search filter, you have to type a natural language prompt to find a pizza place. A three-line if/else block, a dropdown, or a basic index filter would have solved the problem in milliseconds with zero hallucination risk. Instead, the team shipped a conversational wrapper that takes fifteen seconds and regularly gets it wrong, because building the boring thing didn't make for a good quarterly demo.
It happened to me last week. I had a small, specific request: add my infant son to an existing flight booking. One line item. I opened the airline app, tapped Manage Flight, and an AI assistant popped up asking what I wanted to do. I told it I wanted to add an infant to my ticket. It gave me a menu of options, none of which was the thing I had just asked for. I spelled it out again. This time it cheerfully sent me to an FAQ page about infant ticket prices: plenty of detail on what an infant costs, nothing on how to actually add one. I went back. Same loop, a different help section. Back again, another one. Eventually it suggested I email customer support, so I did. The reply came from another AI, which thanked me for my message and advised me to open the app and chat with the customer relations bot. The same bot. The same vicious circle.
So I gave up on all of it. I drove to the physical store and, I will admit, took my frustration out on a poor agent who did not deserve it. She listened for ten seconds, clicked one button, and added my son to the booking. Five minutes, done. A human with a mouse beat the entire conversational stack the airline had spent a fortune building to replace her.
I Built the Spaceship Too
I should be honest, because none of this comes from a clean conscience. The first version of this very website ran on AWS. RDS for a database it did not need, Elastic Beanstalk to orchestrate it, Grafana bolted on top so I could stare at dashboards for traffic that barely existed. A spaceship, for a portfolio. I had built the exact thing I now spend my career tearing down.
Then I saw the bill.
The only thing separating me from the petrol station owner was that I had spent enough years cleaning up other people's over-engineering to recognize my own. So I pivoted. I stripped it to the bone: Eleventy generating plain static files, served by Cloudflare Pages. No database. No cluster. No dashboards.
It did not just get cheaper. It became literally free, faster, and easier to maintain. But the part I did not see coming was what it did to me. When a deploy took twenty minutes and every small change meant babysitting infrastructure, I left the site untouched for years. Strip the complexity away and the loop gets short enough that the work becomes fun again. I wrote about that exact shift in Four Years and One Afternoon. The less time you spend feeding the machine, the more you have for the only things a reader ever actually feels: the writing, and the handful of optimizations that matter.
The Virtue of Prevention
As engineers, our highest virtue shouldn't be how much complexity we can manage. It should be how much complexity we can actively prevent.
The screws that mechanic removed are still missing. The Kubernetes cluster will need a full-time engineer who costs more than the cluster does. The chatbot will get a one-star review from someone who just wanted a pizza.
The customer is still hungry.
Back to Life in Production