Open the codebase of a typical WordPress site. You will find thousands of lines of code: theme files, plugin files, framework files, library files. Scroll through them and ask: what is this code for? What purpose does it serve? What would break if it were removed?
In most cases, you cannot answer these questions. The code exists not because it serves a specific purpose but because it came with the template. It is default code, included code, assumed code. It is there because the theme author thought it might be useful to someone, somewhere. Whether it is useful to this particular client is a question nobody asked.
Intent-driven development inverts this relationship. Every line of code exists because it serves a defined purpose. Nothing is included by default. Nothing is assumed. The codebase is a direct expression of the client's needs, containing exactly what is required and nothing more.
What Intent Means in Code
Intent, in the context of development, means conscious purpose. Code written with intent answers the question "why does this exist?" with a specific, defensible reason tied to client requirements.
A navigation menu exists because users need to move between pages. The specific structure of that menu reflects how this client's users think about the content—not how a theme author imagined users in general might think. The code implements that specific structure, not a generic navigation pattern that must be configured to fit.
A contact form exists because this business needs to receive enquiries. The fields on that form collect exactly the information this business needs to respond effectively—not the fields that a form plugin provides by default. The code implements those specific fields, with validation rules that match this business's requirements.
A content management interface exists because this client's staff need to update the website. The interface reflects how those staff members think about their content—not how a generic CMS organises content for all possible users. The code implements that specific mental model, reducing confusion and errors.
Intent connects code to purpose. Every function, every class, every line can be traced back to a requirement that emerged from understanding the client. Nothing exists just because it came with the package.
The Problem with Template Code
Template-based development inverts intent entirely. The code comes first, pre-written by someone who does not know the client. The client's needs must then be fitted into the code's assumptions.
This inversion has consequences.
Templates include code for features the client will never use. A theme designed for general business use might include portfolio functionality, testimonial carousels, team member displays, and e-commerce hooks. A client who needs none of these still receives the code, adding weight to every page load and complexity to every maintenance task.
Templates encode assumptions that may not match the client's situation. The theme assumes certain content structures, certain navigation patterns, certain visual hierarchies. When client needs diverge from these assumptions, workarounds are required. The workarounds add complexity, and the original assumptions remain embedded in the code, creating permanent friction.
Templates abstract away understanding. The developer configuring a template does not need to understand how it works. They adjust settings without knowing what those settings affect. This abstraction is convenient but dangerous—when something goes wrong, the developer lacks the knowledge to diagnose or fix it.
Templates create dependency. The client becomes reliant on the theme author's continued support. If the author abandons the theme or changes direction, the client's website becomes increasingly difficult to maintain. The code they paid for is not truly theirs; it is licensed, borrowed, dependent.
Writing with Intent
Intent-driven development requires a different process. Instead of selecting templates and configuring options, the developer begins with requirements and writes code to meet them.
This process starts with questions. What does this website need to do? What content will it contain? Who will use it, and how? What actions should users take? What must be managed by staff after launch? These questions define scope not in terms of features but in terms of purposes.
From purposes, requirements emerge. The requirement is not "a slider" but "a way to highlight three key messages on the homepage with visual priority." The requirement is not "a blog" but "a way to publish and organise articles that establishes the business as a thought leader." The language of requirements reflects intent rather than implementation.
From requirements, code is written. Each piece of functionality is implemented specifically for the defined purpose. If the homepage needs to highlight three key messages, the code creates exactly that capability—not a general-purpose slider that could display any number of items with any configuration. The specificity is a feature, not a limitation.
The resulting codebase is lean. Nothing is included speculatively. Nothing exists because it might be useful someday. Everything can be traced to a purpose that was defined before development began.
The Discipline of Exclusion
Intent-driven development requires saying no. It requires excluding functionality that is not explicitly required, even if including it would be easy.
This discipline is difficult. Developers naturally want to build comprehensive solutions. They anticipate future needs and include capabilities proactively. They add features because they can, not because they should.
But every addition has costs. Code that exists must be maintained. Functionality that is present can break. Interfaces that offer options create decisions. The weight of unnecessary capability slows performance, complicates maintenance, and confuses users.
Intent-driven development treats exclusion as a positive act. Choosing not to include something is as deliberate as choosing to include it. The developer asks: does this serve a defined purpose? If not, it stays out, regardless of how easy it would be to add.
This discipline produces websites that do exactly what they need to do. They load faster because they carry no unnecessary weight. They are easier to maintain because there is less to maintain. They are easier to use because irrelevant options do not clutter the interface.
Intent and Client Ownership
When code is written with intent for a specific client, that client owns something meaningful. They own a solution designed for their needs, implemented without dependencies on third-party templates or plugins.
This ownership has practical value. The client is not bound to a theme author's roadmap. They are not vulnerable to plugin abandonment. They are not paying license fees for functionality they do not use. The code is theirs, fully, to maintain, modify, or migrate as they choose.
Ownership also has psychological value. The client knows their website is genuinely theirs. It was not assembled from parts available to anyone; it was crafted specifically for them. This knowledge creates pride in the digital presence and confidence in its foundation.
Template-based websites offer a different kind of ownership—ownership of a configuration. The client owns their specific arrangement of someone else's code. This is lesser ownership, contingent and constrained. The difference matters when businesses think long-term about their digital assets.
The Economics of Intent
Intent-driven development costs more upfront than template configuration. Writing code takes longer than adjusting settings. Understanding requirements takes longer than accepting defaults. The initial investment is higher.
But the total cost of ownership often favours intent. Template sites accumulate costs over time: plugin licenses, security patches for vulnerable code, workarounds for functionality that does not quite fit, and eventually complete rebuilds when the template becomes unmaintainable.
Intent-driven sites have lower ongoing costs. There are no license fees for custom code. Security surface is smaller because unnecessary functionality was excluded. Modifications are straightforward because the code was designed for this specific context. The site lasts longer before requiring replacement.
For businesses that view their website as a long-term asset rather than a short-term expense, intent-driven development often delivers better value despite higher initial costs.
Intent Requires Skill
Not every developer can practice intent-driven development. It requires capabilities that template configuration does not.
It requires the ability to write code. Developers who have only configured templates lack the fundamental skill to create from scratch. They cannot implement functionality that does not exist as a plugin. They cannot debug code they did not write and do not understand.
It requires the ability to understand requirements. Developers must translate business needs into technical specifications. They must ask good questions, interpret answers correctly, and identify needs that clients have not articulated. This translation skill is distinct from coding skill.
It requires the discipline to exclude. Developers must resist the temptation to add functionality speculatively. They must be comfortable with solutions that do exactly what is needed and nothing more. This restraint is psychologically difficult for people who enjoy building.
These requirements make intent-driven development less accessible than template configuration. Fewer practitioners can do it well. Those who can command higher rates. This scarcity is a feature for clients who value the approach—they receive work that most agencies cannot deliver.
A Different Definition of Quality
Template-based development defines quality in terms of appearance and functionality. Does the site look professional? Do the features work? These criteria can be met by configuration.
Intent-driven development defines quality in terms of fit and efficiency. Does every piece of code serve a purpose? Does the site do exactly what the client needs without doing more? Is the codebase as simple as possible while meeting requirements? These criteria require craft.
The difference in definition produces different outcomes. Template sites that meet the first definition may fail the second spectacularly—bloated, generic, full of code that serves no purpose for this client. Intent-driven sites meet both definitions by necessity—they look professional and function correctly because they were designed to, and they fit precisely because nothing else was included.
Clients who understand this distinction choose intent over template. They recognise that a leaner, more purposeful website serves their business better than a feature-rich template that happens to include what they need among much they do not.
The question is not whether a website can be built from templates. It clearly can. The question is whether the result serves the client as well as code written with intent for their specific situation. The answer, consistently, is no.
Intent-driven development is not the only way to build websites. But it is the only way to build websites that are exactly what the client needs and nothing more. For businesses that value precision over abundance, that distinction makes all the difference.