For years, I described myself as a WordPress developer. The label seemed accurate. I built websites using WordPress. I wrote custom themes and plugins. I understood the platform's architecture deeply enough to extend it in sophisticated ways. WordPress developer described what I did.
I no longer use that title. Not because my skills have changed, but because the title's meaning has changed. "WordPress developer" now encompasses such a vast range of competencies—from genuine software engineering to basic template configuration—that it communicates nothing meaningful about capability.
When everyone is a WordPress developer, no one is.
The Dilution of a Title
WordPress's success created the conditions for its title's dilution. As the platform grew to power over forty percent of the web, demand for WordPress expertise exploded. That demand was met not by an expansion of genuine developers but by an influx of configurators who adopted the developer title without possessing developer skills.
The path to calling yourself a WordPress developer became trivially easy. Watch some YouTube tutorials. Install a theme. Configure some plugins. Build a few websites for friends or family. Update your LinkedIn profile. You are now, by self-declaration, a WordPress developer.
No certification body validates the title. No professional standards define its requirements. No licensing regime restricts its use. Anyone can claim it, and millions have. The title has expanded to include people whose skills begin and end with interface navigation.
This expansion diluted the title's meaning. When I said "WordPress developer," I meant someone who writes PHP, who understands hooks and filters, who can create custom functionality from requirements. But the listener might hear "someone who installs themes and plugins," because that is what most self-described WordPress developers actually do.
Communication requires shared meaning. The title no longer provides it.
The Guilt by Association
Beyond semantic dilution, the WordPress developer title carries associations I no longer wish to bear.
The WordPress ecosystem has become synonymous with certain practices: template-based development, plugin dependency, bloated codebases, security vulnerabilities, performance problems. These associations are not entirely fair—excellent work happens on WordPress—but they are widespread and often accurate.
When I identified as a WordPress developer, I inherited these associations. Potential clients assumed I worked like other WordPress developers they had encountered. They expected template customisation rather than custom development. They anticipated plugin solutions rather than coded functionality. They braced for the performance and security issues they had experienced before.
Correcting these assumptions required constant explanation. "I'm a WordPress developer, but not like those WordPress developers. I write custom code. I don't use page builders. I build themes from scratch." The explanation worked sometimes, but it positioned me as an exception to a rule rather than as a professional with distinct capabilities.
Abandoning the title eliminated the need for constant clarification. When I describe myself as a web developer who works primarily with PHP, expectations align more closely with reality. The conversation starts from neutral ground rather than from assumptions I must overcome.
The Platform Problem
My discomfort with the WordPress developer title reflects deeper discomfort with what WordPress has become.
WordPress originated as blogging software and evolved into a general-purpose content management system. This evolution succeeded commercially—WordPress powers an enormous portion of the web—but it created a platform burdened by legacy decisions and bloated by feature accumulation.
The block editor exemplifies the problem. Introduced to compete with page builders, it added substantial complexity to what was once a straightforward content editing experience. Sites must now load JavaScript frameworks to render editing interfaces. The simplicity that made WordPress accessible became obscured by ambition to be everything for everyone.
The plugin ecosystem compounds the bloat. WordPress core cannot include every feature users might want, so functionality fragments across thousands of plugins with varying quality, security practices, and maintenance commitments. A typical WordPress site runs dozens of plugins, each adding code, creating potential conflicts, and expanding attack surfaces.
Building excellent websites on WordPress remains possible, but it requires working against the platform's grain. You must strip away defaults, reject common practices, and impose discipline that the ecosystem does not encourage. The effort is substantial, and the result still carries WordPress's overhead.
Identifying with a platform I increasingly work around felt inauthentic. My best work happens despite WordPress, not because of it. The title suggested alignment with a platform from which I had substantially diverged.
The Search for Authentic Identity
Abandoning the WordPress developer title created an identity vacuum. What should I call myself instead?
"Web developer" is accurate but vague. It encompasses everything from front-end specialists to back-end engineers to full-stack generalists. It communicates that I build things for the web without specifying what kind of things or how.
"PHP developer" is more specific but potentially limiting. It emphasises a language rather than an outcome. Clients care about websites, not about the languages used to build them. Leading with PHP risks attracting only those who have already decided on technology rather than those seeking solutions to problems.
"Full-stack developer" describes capability but has its own dilution problems. Like WordPress developer, the title has been claimed by people with varying skill levels. It also emphasises technical breadth in ways that may not serve all conversations.
I have settled on contextual descriptions rather than fixed titles. When technical specificity matters, I describe my stack: PHP, MySQL, vanilla JavaScript, semantic HTML and CSS. When outcomes matter, I describe my focus: bespoke websites built from requirements rather than templates. When process matters, I describe my approach: discovery, architecture, custom development.
This flexibility sacrifices the convenience of a single title for the accuracy of situated description. It requires more words but creates fewer misunderstandings.
The Broader Professional Crisis
My experience reflects a broader professional crisis in web development. Titles throughout the industry have been diluted by the same forces that diluted WordPress developer.
"Web designer" now includes both trained visual designers and people who select templates from marketplaces. "Front-end developer" includes both JavaScript engineers and HTML email assemblers. "UX designer" includes both researchers who conduct user studies and decorators who add animations to interfaces.
This dilution damages everyone. Genuine professionals struggle to differentiate themselves from pretenders using the same titles. Clients struggle to evaluate service providers when titles communicate nothing reliable about capability. The industry struggles to maintain standards when anyone can claim any title.
Some professions address this through certification and licensing. Doctors, lawyers, and engineers face barriers to using their professional titles. These barriers are imperfect but create some assurance that titles correspond to competencies.
Web development has resisted formalisation. The industry values accessibility and self-taught practitioners. Barriers to entry would exclude people who have developed genuine skills through non-traditional paths. The freedom to call yourself a developer regardless of credentials has enabled remarkable careers.
But that freedom has costs. Without shared definitions, titles become meaningless. Without standards, quality varies wildly. Without barriers, the field floods with underskilled practitioners who damage client trust and industry reputation.
What Comes Next
I do not have a solution to the industry's title crisis. Formalisation would create problems even as it solved others. The current state is unsatisfactory but not easily remedied.
What I can control is my own practice. I can describe my work accurately. I can demonstrate capability through portfolio and process rather than relying on titles to communicate it. I can ask questions that reveal what clients actually need and explain honestly whether I can provide it.
I can also be explicit about what I am not. I am not a template configurator. I am not a plugin installer. I am not someone who purchases themes and resells them as custom work. These negations are almost as important as positive descriptions in an industry where titles have been so thoroughly compromised.
Stopping calling myself a WordPress developer was a small act with limited impact. It changed a line on my website and a phrase in conversations. But it represented something larger: a refusal to accept terminology that no longer communicated truth.
The web development industry needs more such refusals. It needs practitioners who insist on accurate description even when vaguer terms would be easier. It needs clients who probe beyond titles to understand actual capabilities. It needs honesty about what we do and what we call it.
I build bespoke websites using PHP and modern web standards. I write custom code rather than configuring templates. I engineer solutions from requirements rather than assembling them from plugins. These descriptions are longer than "WordPress developer," but they are true in ways that title no longer is.
Truth in professional identity may seem like a small thing. In an industry rife with misrepresentation, it is anything but.