I didn’t expect that a small website project would turn into a front-row seat to the enshittification of web development, but that’s exactly what happened. What started as a simple build quickly became something else entirely, not because the problem was hard, but because the environment around it has changed.
Lately, I’ve noticed a shift that goes beyond just one project. AI tools have made it incredibly easy for anyone to generate code, use technical jargon, and sound like they know what they are doing. The barrier to entry hasn’t just lowered, it’s practically disappeared. And with that, a new kind of confidence has taken over.
I’m not talking about real expertise. I’m talking about surface-level fluency that feels convincing until you scratch it. People who have never spent a day actually building or maintaining systems can now produce answers, architectures, and opinions instantly. They sound polished, decisive, and authoritative. If you didn’t know better, you’d assume they’ve been doing this for years.
Table of Contents
It reminds me of the kind of energy you see mocked in communities like r/linkedinlunatics, except now it’s leaking into actual development work. Everyone sounds like a thought leader. Everyone has a “best practice.” And somehow, everything is overengineered before it even works.
There’s also this strange pop culture version of technical skill creeping in. The kind where typing fast on a laptop equals mastery. It’s the same fantasy you see in Hackers, where Angelina Jolie’s character can manipulate massive systems with a few keystrokes and a cool attitude. That used to be obviously fictional. Now, it feels like some people genuinely believe that’s how real-world development works.
The result is a growing gap between how things sound and how they actually function. Projects get filled with unnecessary complexity, AI-generated code gets stacked on top of itself, and no one wants to admit they don’t fully understand what’s happening underneath.
This is the real enshittification of web development. It’s not just worse code. It’s a culture where confidence is cheap, understanding is optional, and looking like an expert is often valued more than actually being one.
I Joined a Woodworkers Group and Didn’t Expect a Web Disaster
I thought I was stepping away from the noise.
After dealing with the same patterns in web development over and over, I decided to take a break and focus on something more grounded. Woodworking felt like the perfect escape. Real materials, real skills, no endless debates about frameworks or AI tools. I joined a Facebook group expecting to learn, maybe share a few ideas, and just stay out of the usual chaos.
That lasted about five minutes.
A Simple Question, Complicated Answers
Someone asked a simple question. They wanted to start selling their woodworking products online and were wondering if it was worth setting up a shop. A completely reasonable question. But the responses quickly turned into something I’ve seen too many times before.
Most people immediately started recommending bloated page builders, the kind bundled with hosting platforms that promise easy setup but deliver slow, clunky websites. Performance, structure, and long-term thinking weren’t even part of the conversation. It was all about speed and convenience, with no thought about what happens next.
Then the “web experts” showed up.
You could spot them instantly. Confident tone, strong opinions, and of course, links to their own websites as proof of credibility. But when I actually looked at those sites, it was the same story. Built with the same page builders they were promoting, poor performance, weak SEO, and barely any real structure behind them. It felt like I had walked right back into the same environment I was trying to avoid.
When Confidence Replaces Competence
Some of those sites were supposed to be online shops, but they were missing the most basic things. No clear business name. No address. No shipping or return policies. Just a checkout button and hope. I’m not even going to get into accessibility standards or compliance, because those weren’t even part of the conversation.
Personally, I would never buy anything from a website like that. And I doubt most people would, at least not more than once.
What really stood out, though, was what happened next. A few people started saying their websites weren’t getting traffic or sales. And instead of questioning the foundation they had built on, they blamed web development, SEO, or how difficult it is to succeed online.
But with websites like that, it’s not surprising.
It’s just human nature. When something doesn’t work, it’s easier to blame the system than to question the advice you followed in the first place.
Out of Curiosity, I Checked a Few Websites People Were Recommending
At some point, curiosity got the better of me.
After seeing so many confident recommendations and bold claims, I started opening the links people were sharing. If they were positioning themselves as experts, I wanted to see what they had actually built. It didn’t take long to understand what was really going on.
Under the Hood, It Fell Apart
The moment I looked at the code, everything made sense. These websites were weighed down by heavy DOM structures, layers of nested elements that served no real purpose other than making things harder to load and maintain. On top of that, there were unnecessary scripts everywhere. Features stacked on features, most of them unused, all of them slowing things down.
Load times were poor, responsiveness was inconsistent, and the overall experience felt fragile. It wasn’t just a technical issue. It was the direct result of relying on tools without understanding what they produce.
No Foundation, No Trust
But the problems didn’t stop at performance.
Many of these sites lacked even the most basic elements of a real business. There was no clear brand identity. No consistent voice, no visual direction, nothing that would make a customer remember or trust the brand.
Key pages were missing too. No return policy. No shipping information. Sometimes not even a proper contact page. And when there was contact information, it often pointed to public domain email addresses like Gmail, Hotmail, or even Yahoo.
That might seem harmless at first, but it creates an immediate trust gap. Real businesses typically use domain-based emails because they are tied to ownership and brand identity, while free email services make it harder to verify who is actually behind a site.
It also opens the door to confusion and risk. In some cases, attackers can use techniques like email spoofing, where they forge the “from” address in an email to make it look like it came from a legitimate business. From a customer’s perspective, that can be dangerous. Someone could impersonate the shop, send fake order updates, payment requests, or refund notices, and the customer might not realize it is fraudulent because the message appears to come from the correct brand.
That is exactly why proper domain setup, verified email authentication, and clear business identity matter. Without them, anyone can step into that gap and pretend to be you, and the customer has no reliable way to tell the difference.
These were supposed to be online shops, but they felt unfinished and untrustworthy.
Looking at it all together, it became obvious why these solutions fail. It’s not just about bad tools or bad luck. It’s what happens when execution is driven by convenience instead of understanding. The code reflects it, the structure reflects it, and ultimately, the results reflect it too.
Then the “Web Experts” Appeared in the Comments
After going through a few of the websites people were recommending, I started noticing a pattern I honestly didn’t expect to see so consistently.
The comment section slowly shifted. What began as simple advice turned into self-promotion. The “web experts” started appearing with confident takes and service offers, positioning themselves as professionals who could solve everything with Divi, Elementor, Oxygen, or similar page builder setups packaged as “premium solutions.”
So I did what I had already been doing. I checked their websites.
Same Tools, Same Problems
What I found was almost indistinguishable from the earlier “common Joe” websites people were building.
Slow load times. Bloated layouts. Overloaded DOM structures. Endless nested sections created by page builders trying to solve every possible design scenario at once. On the surface, they looked slightly more polished, but under the hood it was the same story repeated with a different label.
The performance issues were still there. Images not optimized, scripts stacked without restraint, and layouts that felt heavy even on simple pages. Nothing about it felt truly intentional or engineered with long-term maintenance in mind.
No Real Difference Between “Expert” and Beginner
What surprised me most was how little separation there actually was between the “experts” and the people asking basic questions in the first place.
Both groups were using the same tools. Both were producing similar results. And both were inheriting the same limitations without really questioning them. The only real difference was confidence in how it was presented.
And that’s where it gets uncomfortable.
Because when everyone is using the same abstractions without understanding what’s underneath, expertise becomes almost indistinguishable from imitation. It becomes harder to tell who actually knows what they are doing and who is just repeating what worked once in a different context.
In the end, it started to feel like a loop. People learning from other people who never really built anything solid in the first place, all reinforcing the same patterns, all convinced they are doing it the “right” way.
Blind leads blind.
I See the Same Excuses Every Time: “WordPress Is the Problem”
After going through enough of these conversations and websites, I started noticing a recurring pattern in how problems get explained.
One of the most common takes is that WordPress is the issue. It gets blamed for everything: slow performance, poor SEO, broken layouts, and unreliable websites. But when you actually look closer, the platform is rarely the real problem.
In most cases, it comes down to plugin overload, poor configuration, and complete neglect of maintenance. It’s not unusual to see sites running 30 or more plugins, many of them doing overlapping or unnecessary tasks. On top of that, there are often dozens of pending updates that have been ignored for months. At that point, any system would struggle.
The tool is not what’s failing. The way it’s used is.
I’ve Learned Social Networks Are a Terrible Place to Plan Real Projects
The deeper I looked into this space, the more obvious another pattern became. Social networks are one of the worst places to plan or evaluate real technical work.
Whether it’s Facebook groups, LinkedIn-style discussions, or comment threads under posts, the advice is often a mix of AI-generated explanations, recycled opinions, and engagement-driven hot takes. Most of it sounds confident, but very little of it is grounded in actual hands-on experience.
It creates a strange illusion where popularity replaces credibility. The most visible advice is not necessarily the most correct, just the most engaging.
I See the Same Pattern Daily: Viral Posts With No Substance
This shows up even more clearly in viral posts.
You see emoji-heavy “insights,” short motivational breakdowns, and simplified explanations of complex topics. They are designed to be shareable, not accurate. There are rarely any real case studies, benchmarks, or measurable results behind them.
And yet, these posts still shape how people think about development, tools, and best practices.
No data. No accountability. Just repetition that feels like knowledge.
Over time, it becomes less about what actually works and more about what sounds right in a feed.
Oh btw look how well our website performs according to PageSpeed Insights.
I Asked Myself: Would You Trust These People in Any Other Trade?
At some point, I stopped looking at websites and started looking at the bigger picture.
And I asked myself a pretty simple question. What would happen if I walked up to someone with 20 years of experience in a skilled trade, like an electrician or a woodworker, and started confidently telling them how to do their job?
I can already imagine the response. If I tried explaining wiring to an electrician who has been doing it for decades, I would probably get that look. The one that says they are trying to decide whether I’m joking or just dangerously uninformed. And if I doubled down, I’d likely get a very short explanation of why I should maybe step away from the tools.
The point is, in most real-world trades, experience is visible and respected. There is a clear boundary between learning and pretending.
But in web development and tech, that boundary gets weirdly blurry. Suddenly, everyone has opinions on architecture, performance, SEO, scalability, and “best practices,” often based on a few tools, tutorials, or AI-generated explanations. And sometimes it feels like confidence matters more than actual depth of understanding.
It raises another uncomfortable question. Are some people genuinely overconfident, or is the system just rewarding the appearance of expertise? I don’t think it’s always about arrogance or trying to take money for high-end services. In many cases, it’s simpler than that. People genuinely believe they are doing things correctly because the tools make it look that way.
It reminds me a bit of the story of the three little pigs. One builds a house quickly out of straw, another uses sticks, and only the last one takes the time to build something solid with bricks. At a glance, the straw house still looks like a house. Until it isn’t.
And that’s kind of what a lot of modern web projects feel like. Everything looks fine on the surface, until real pressure shows up.
We’re Surrounded by Confident, Underqualified Experts
After going through all of this, I kept coming back to the same uncomfortable realization.
We are surrounded by people who sound confident, speak in technical terms, and present themselves as experts, but a lot of that confidence is not backed by real depth of experience. AI tools, low barriers to entry, and social media have made it incredibly easy to produce answers, opinions, and even entire “strategies” without ever actually building or maintaining anything at scale.
The result is a lot of noise. And in that noise, real expertise often gets drowned out.
Where This Leads: The Enshittification of Web Development
This is where the enshittification of web development really starts to show itself. Not just in bloated websites or slow performance, but in expectations, decision making, and how people spend their money.
Because at the end of the day, people are voting with their budget. When someone pays for a website, they are not just buying a design. They are investing in a foundation for their business. And if they expect instant results, overnight traffic, and effortless sales from a cheap, template based setup, disappointment is almost guaranteed.
Then the cycle begins. The website underperforms, and instead of questioning the approach, people often blame “expensive developers” or assume custom development is unnecessary. But very little time is spent on research in the first place. A week of understanding the difference between drag and drop builders and custom development could completely change those expectations.
Custom development is not about being fancy. It’s about control, performance, maintainability, and reducing long term technical debt. It often means fewer surprises later, lower maintenance costs, and systems that do exactly what a business needs instead of what a generic template allows.
Drag and drop tools can absolutely work for some cases, but they come with tradeoffs. Those tradeoffs often show up later as slow performance, plugin overload, or structural limitations that are expensive to fix once the site grows.
In a way, it goes back to the three little pigs. The straw house is quick and cheap, and it looks fine at the beginning. The stick house is slightly better, but still fragile. Only the brick house takes real effort and time to build properly. The difference only becomes obvious when pressure comes.
And in web development, that pressure eventually shows up as traffic, customers, scaling, and real business demands.
So the real question is not what is cheapest to build today, but what will still stand when it actually matters tomorrow.