A client describes their requirements. They need a booking system. They need a custom form that integrates with their CRM. They need a particular type of image gallery. They need functionality specific to how their business operates.
Twenty years ago, the web developer would have responded: "I'll build that for you."
Today, the response is different: "I'll find a plugin for that."
This shift in language reveals a fundamental transformation in the web development industry. What was once a profession defined by creation has become a profession defined by assembly. The skills, the mindset, and the very nature of the work have changed—and not for the better.
The Plugin Economy
The WordPress plugin repository contains over sixty thousand plugins. Third-party marketplaces add thousands more. For virtually any functionality a client might request, a plugin exists. Often, dozens of plugins exist, competing for the same use case.
This abundance creates an irresistible temptation. Why spend hours developing custom functionality when you can install a plugin in minutes? Why learn the intricacies of payment gateway integration when WooCommerce handles it automatically? Why write database queries when a plugin abstracts them away?
The economics seem obvious. Plugin installation is fast, cheap, and low-risk. Custom development is slow, expensive, and uncertain. Agencies that embrace plugins can deliver more projects with fewer developers, maximising profit margins.
But this calculation ignores crucial factors that only manifest over time. The true cost of plugin dependency is paid by clients, often long after the agency has moved on.
The Hidden Costs of Plugin Culture
Every plugin added to a WordPress site carries costs that are rarely discussed during the sales process.
There is the performance cost. Each plugin loads its own stylesheets, scripts, and database queries. A site with thirty plugins—common in the industry—executes thirty separate codebases on every page load. The cumulative effect is sluggish performance that frustrates users and damages search rankings.
There is the security cost. Each plugin represents an attack surface. Plugin developers vary wildly in their commitment to security practices. Many plugins are abandoned by their creators, receiving no updates even as vulnerabilities are discovered. A single compromised plugin can expose the entire site to attackers.
There is the maintenance cost. Plugins require updates. Updates sometimes break other plugins, or the theme, or core functionality. Sites with extensive plugin dependencies become brittle, requiring constant attention to prevent conflicts. The agency that installed the plugins often sells ongoing maintenance contracts to manage the complexity they created.
There is the flexibility cost. Plugins make assumptions about how functionality should work. When client requirements diverge from those assumptions, the plugin becomes a constraint rather than a solution. Customising plugin behaviour often requires more effort than building the functionality from scratch would have.
There is the ownership cost. Premium plugins require annual license renewals. The client pays perpetually for functionality that could have been built once and owned outright. Over a five-year website lifespan, license fees often exceed what custom development would have cost.
What "I'll Build That" Actually Means
When a developer says "I'll build that for you," they are making a commitment that extends far beyond code production. They are committing to understanding the requirement deeply, to designing a solution that fits the specific context, and to taking responsibility for the outcome.
Building requires analysis. What exactly does the client need? How will users interact with the functionality? What edge cases must be handled? What happens when requirements evolve? The developer must ask these questions because they cannot rely on a plugin author to have anticipated this particular client's needs.
Building requires design. How should the functionality be structured? What is the cleanest implementation that meets the requirements? How can the code be written to facilitate future modifications? The developer must make architectural decisions rather than accepting the architecture imposed by a plugin.
Building requires craft. The code must be clean, efficient, and maintainable. It must handle errors gracefully. It must perform well under load. It must be secure against common attack vectors. The developer stakes their professional reputation on the quality of their work.
This is fundamentally different from installation. Plugin installation requires only the ability to click buttons and configure settings. It demands no understanding of underlying mechanics, no responsibility for code quality, no commitment to long-term maintainability.
The Skill Erosion
Plugin culture has eroded the skill base of the web development industry. When the default response to any requirement is "find a plugin," developers never develop the capabilities that distinguish professionals from amateurs.
Consider what happens to a developer who spends their career installing plugins. They never learn to structure a database efficiently. They never learn to write secure authentication systems. They never learn to optimise queries for performance. They never learn to architect solutions that scale gracefully.
These skills atrophy through disuse. The developer becomes dependent on their tools in a way that true craftspeople never are. When faced with a requirement that no plugin addresses, they are helpless. When asked to modify plugin behaviour, they are lost. When plugins conflict or break, they can only wait for updates or search for alternative plugins.
This skill erosion propagates through the industry. Senior developers who might have mentored juniors in proper development practices instead mentor them in plugin selection. Training programmes focus on tool proficiency rather than fundamental competencies. The profession hollows out, retaining the title of developer while abandoning the substance.
The Responsibility Question
When something goes wrong with custom code, responsibility is clear. The developer who wrote it must fix it. Their reputation depends on their code working correctly.
When something goes wrong with a plugin, responsibility becomes diffuse. The agency blames the plugin developer. The plugin developer blames the hosting environment. The hosting provider blames another plugin. Everyone points elsewhere while the client suffers.
This diffusion of responsibility is attractive to agencies. They can deliver quickly, collect payment, and outsource accountability to third parties. When problems emerge, they are positioned as intermediaries rather than responsible parties.
But professional responsibility cannot be outsourced. When an agency recommends and installs a plugin, they are vouching for it. They are telling the client that this solution is appropriate for their needs. They are taking a commission on someone else's work. The ethical burden remains, even if practical accountability has been obscured.
The developer who says "I'll build that for you" accepts responsibility fully. They cannot blame a third party because there is no third party. Their work succeeds or fails on its own merits. This accountability drives quality in a way that plugin culture cannot replicate.
When Plugins Make Sense
This critique should not be read as absolute opposition to plugins. There are contexts where plugin usage is appropriate and even advisable.
Complex, standardised functionality like payment processing or email delivery benefits from plugins. These domains involve regulatory compliance, security requirements, and integration complexities that individual developers should not attempt to replicate. A well-maintained payment gateway plugin is safer than a custom implementation.
Functionality that is genuinely generic—not specific to the client's unique needs—can appropriately use plugins. Contact forms, basic SEO tools, and image optimisation are examples where plugins often represent sensible choices.
The distinction is between plugins as tools and plugins as substitutes for thinking. A developer who selects a payment plugin after evaluating security practices, update history, and performance impact is exercising professional judgment. A developer who installs whatever plugin appears first in search results is abdicating professional responsibility.
Reclaiming the Craft
The question in the title—when did "I'll find a plugin" replace "I'll build that"—has a dispiriting answer. It happened gradually, as economic pressure favoured speed over substance, as tool dependency became normalised, as the industry forgot what development actually means.
Reclaiming the craft requires remembering. It requires developers who take pride in their code, who view custom development as the default rather than the exception, who understand that professional responsibility cannot be delegated to third parties.
It requires clients who demand more than assembly. Who ask whether proposed solutions are custom or off-the-shelf. Who understand that the cheapest option often becomes the most expensive over time. Who value ownership over license dependencies.
It requires honesty about what we have lost. The web development industry has become, in too many cases, a plugin installation industry. We have retained the language of development while abandoning its practice.
The first step toward recovery is acknowledging the problem. The second is choosing differently. When a client describes a requirement, the response should be: "I'll build that for you." And then, actually building it.