Watch a typical web agency begin a new project. Within hours of signing the contract, someone is already searching plugin repositories. Contact form plugin. Slider plugin. SEO plugin. Booking plugin. The shopping list grows before anyone has asked the fundamental question: what does this client actually need?
This is dependency-first development. It assumes that solutions exist before problems are understood. It treats every client as a collection of generic requirements that can be satisfied by generic tools. It prioritises the agency's convenience over the client's specific situation.
The alternative—discovery before dependency—inverts this approach entirely. It insists that understanding must precede implementation. It recognises that every client operates in a unique context that demands unique consideration. It treats the plugin library as a last resort rather than a first instinct.
What Discovery Actually Means
Discovery is not a box-ticking exercise. It is not a questionnaire completed before the "real work" begins. It is the foundation upon which everything else rests, and it demands genuine intellectual engagement.
Proper discovery explores the client's business model. How do they generate revenue? Who are their customers? What problems do they solve? How do they differ from competitors? These questions may seem distant from web development, but they are essential. A website that does not understand the business it represents cannot effectively serve that business.
Discovery examines the client's current situation. If they have an existing website, what works and what fails? What do their analytics reveal about user behaviour? Where do visitors arrive from, and where do they drop off? What feedback have they received from customers? This forensic examination often reveals insights that the client themselves had not recognised.
Discovery investigates the competitive landscape. What are similar businesses doing online? Where are the gaps and opportunities? What conventions exist in the industry, and which should be followed versus challenged? Understanding the context in which a website will compete is essential to making it competitive.
Discovery probes the client's aspirations. Where do they want the business to be in three years? What role should the website play in that growth? What would success look like, and how would it be measured? These forward-looking questions ensure the website is built for where the client is going, not just where they are.
Why Dependency-First Fails
When an agency begins with plugins, they have already constrained the solution space. Each plugin comes with assumptions about how functionality should work. These assumptions may not align with the client's actual needs, but once the plugin is installed, the client must adapt to its limitations.
Consider a booking system. A generic booking plugin assumes certain workflows: select a service, choose a time, provide contact details, confirm. But what if the client's business requires a consultation before booking? What if availability depends on staff qualifications that the plugin cannot model? What if the booking process needs to integrate with existing business systems in ways the plugin does not support?
The dependency-first agency forces the client's business into the plugin's model. They explain that certain requirements are "not possible" or would require "custom development" at additional cost. The client, who does not understand that the limitation is artificial, accepts these constraints. The website launches with functionality that almost meets their needs but never quite fits.
This pattern repeats across every aspect of the site. The theme imposes layout constraints. The page builder limits design possibilities. The plugin ecosystem determines what features are available. The client receives a website shaped by tools rather than by their business requirements.
The Economics of Discovery
Agencies resist discovery because it costs time, and time costs money. A proper discovery process might take days or weeks. It requires senior staff who can ask intelligent questions and interpret the answers. It delays the start of "production work" and extends project timelines.
This resistance reflects short-term thinking. Discovery is an investment that pays returns throughout the project lifecycle.
Projects that begin with thorough discovery experience fewer revisions. When the team understands what they are building and why, they make better decisions at every stage. The client sees work that aligns with their expectations because those expectations were properly understood from the start.
Discovery reduces scope creep. Many projects spiral out of control because requirements were never properly defined. New requests emerge constantly as the client sees work that does not match their unarticulated expectations. Proper discovery surfaces these expectations early, when addressing them is cheap rather than expensive.
Discovery builds client relationships. When an agency invests time in understanding a business, the client feels valued. They recognise that they are being treated as a unique entity rather than a transaction. This relationship foundation supports ongoing collaboration and future work.
Discovery produces better outcomes. Websites built on genuine understanding outperform those built on assumptions. They convert better because they address actual user needs. They support the business better because they align with actual business processes. They last longer because they were designed for the client's specific situation rather than generic requirements.
Discovery in Practice
Implementing discovery-first development requires structural changes to how agencies operate.
It begins with the sales process. Rather than quoting based on a brief description, agencies should propose a paid discovery phase. This phase produces a detailed specification that forms the basis for accurate project pricing. Clients who baulk at paying for discovery reveal themselves as poor fits—they want cheap assembly, not considered design.
Discovery requires appropriate personnel. Junior staff can execute discovered requirements, but discovery itself demands experience. The person conducting discovery must understand business strategy, user experience principles, and technical possibilities. They must know what questions to ask and how to interpret the answers.
Discovery demands documentation. The insights gathered must be captured in forms that guide subsequent work. This might include user personas, journey maps, functional specifications, or strategic briefs. The format matters less than the discipline of recording what was learned.
Discovery should inform technology choices. Only after understanding what the client needs should the team consider how to build it. Sometimes a plugin is appropriate. Sometimes custom development is required. Sometimes the entire technology stack should be reconsidered. These decisions should follow from requirements, not precede them.
The Client's Role in Discovery
Discovery is not something done to clients; it is done with them. The process requires their active participation and honest engagement.
Clients must make time for discovery conversations. These are not optional meetings to be delegated to junior staff. The people who understand the business—founders, directors, key stakeholders—must participate directly. Their insights cannot be captured secondhand.
Clients must answer honestly. Discovery surfaces uncomfortable truths: the marketing strategy that is not working, the customer segment that is being neglected, the competitive threat that is being ignored. Clients who conceal these realities undermine the discovery process and ultimately receive websites that do not address their actual situations.
Clients must trust the process. Discovery takes time, and results are not immediately visible. The client is paying for conversations and documents rather than tangible website progress. They must understand that this investment produces better outcomes than rushing into production.
Beyond the Plugin Library
The plugin library is not inherently bad. Plugins can provide genuine value when they align with genuine needs. The problem is reaching for plugins before those needs are understood.
Discovery-first development does not reject plugins categorically. It subjects them to scrutiny. Does this plugin actually address the client's specific requirement? Does it impose constraints that conflict with business processes? Does it introduce dependencies that will cause problems over time? These questions can only be answered after discovery has revealed what the client actually needs.
Sometimes the answer is yes, a plugin is appropriate. More often, discovery reveals that the client's needs are more specific than any plugin anticipates. In these cases, custom development—code written specifically for this client's situation—is the only responsible choice.
The agency that understands its client can make this determination intelligently. The agency that reaches for plugins before asking questions cannot. They are guessing, and their clients pay the price for those guesses.
A Different Starting Point
Every project begins somewhere. Dependency-first development begins with tools: what themes are available, what plugins might work, what the agency already knows how to build. Discovery-first development begins with questions: who is this client, what do they need, how can we serve them?
The starting point determines the destination. Projects that begin with tools produce tool-shaped solutions. Projects that begin with understanding produce solutions shaped by actual needs.
Discovery before dependency is not merely a process improvement. It is a statement of values. It declares that clients matter more than convenience, that understanding matters more than speed, that craft matters more than efficiency.
The plugin library will still be there after discovery is complete. But its role will be different—a resource to be consulted rather than a crutch to be leaned upon. That difference transforms the entire nature of the work.