What a Craft CMS developer actually needs to know

When a client receives a quote from a Craft CMS developer, the number on the page often feels disconnected from what they can see. A few template changes. Some new fields. A contact form. The visible work rarely accounts for the rate. What accounts for it is everything else: the knowledge, tooling, experience and judgement that a developer brings to every project whether or not it is obvious.

This article breaks down what a competent Craft CMS developer actually needs to carry. Not as a justification for any particular rate, but as a clear account of what the work involves.

Craft CMS is not a simple tool to learn

Craft CMS is built on PHP, with Yii 2 as the underlying framework and Twig as its templating language. Each of these is a separate discipline. A developer working on a Craft site needs to be comfortable across all three, because problems rarely stay in one layer. A slow page might be a Twig loop issue, a missing database index, or a poorly configured eager-loading query. Diagnosing it requires understanding all of them.

Craft 6, currently in development, is migrating its foundation from Yii to Laravel. That is a significant shift in the underlying architecture. A good Craft developer is already tracking this, because the sites they build today need to be upgradeable tomorrow.

Content modelling is where most Craft decisions are made

The most consequential work in a Craft project often happens before a single line of template code is written. Content modelling, specifically deciding how sections, entry types, Matrix fields and relationships are structured, determines how easy or difficult the site will be to manage for years. Get it wrong and editors struggle with confusing field layouts, developers inherit tangled queries, and migrations become painful.

This is a skill that takes time to develop. It requires understanding both the technical constraints of the CMS and the real-world workflows of the people who will use the control panel. Most clients never see this work. It happens in a planning document or a whiteboard session, not in a commit.

The front-end stack is separate from Craft itself

Craft handles content. The front end is a different set of concerns entirely. A Craft CMS developer working on production sites typically needs to be competent in HTML, CSS, JavaScript, and a build toolchain. Most commonly Vite, though Webpack remains common on older projects. On modern builds, Tailwind CSS has become the standard for utility-first styling, and Alpine.js or HTMX handle lightweight interactivity without reaching for a full JavaScript framework.

Each of these tools has its own ecosystem, its own update cycle, and its own failure modes. Knowing how they interact with Craft's asset pipeline, and how to debug when they do not, is part of the job.

A Craft CMS developer needs to know the plugin ecosystem

Craft has a small but well-maintained plugin ecosystem. A developer who works regularly with Craft will know which plugins are reliable, which are abandoned, and which introduce performance or security risks. SEOmatic handles metadata and structured data. Blitz manages static page caching. Feed Me handles data imports. Commerce adds a full e-commerce layer. Each requires configuration, not just installation.

Knowing which plugin solves a problem and which one creates a new one is the kind of knowledge that does not appear on a CV but shows up in the quality of a finished site.

Servers, environments and deployment are not optional knowledge

Craft CMS is self-hosted. That means the developer is often responsible for ensuring the hosting environment meets Craft's requirements: the right PHP version, the right extensions, database configuration, file permissions, queue workers for background jobs. On a managed platform this is handled for you. On a VPS or a client's existing server, it is not.

Beyond the server itself, a professional developer maintains a reliable local development environment (typically DDEV or Laravel Herd) and a deployment workflow that does not involve manually uploading files over FTP. Git-based deployments, environment variable management, and running database migrations safely on live sites are everyday operational concerns.

Security and updates are ongoing responsibilities

Craft releases updates regularly, and so do its plugins. Applying those updates is not always as simple as running a command. It sometimes requires testing against custom templates, checking for deprecated APIs, and verifying that third-party integrations still work. A developer who understands the update process, and knows when to hold back a release until it has been tested, is protecting the site from both vulnerabilities and self-inflicted breaks.

Security also covers how the site is configured: preventing information disclosure through error messages, setting appropriate headers, managing admin access, and knowing what an attacker would look for in a PHP application running on a public server.

Client communication is part of the technical work

A Craft CMS developer working directly with clients spends a meaningful portion of their time not writing code. Translating a client's business requirements into a content model requires asking the right questions, listening carefully, and being willing to push back when a proposed structure will not work. That is a consultative skill, not a technical one.

The same applies to explaining technical constraints in plain language, writing documentation for editors who will manage the site after handover, and scoping work accurately enough that projects do not run over. Clients who have worked with developers who communicate well know how much it changes the experience of a project.

Working with IT teams and existing infrastructure

On projects for larger organisations, a Craft developer is rarely the only technical person in the room. They may need to work with an in-house IT team, a DevOps function, or a managed hosting provider with its own constraints and approval processes. That means understanding how to communicate requirements clearly, respecting existing security policies, and adapting deployment approaches to fit an organisation's infrastructure rather than assuming a clean slate.

This kind of work requires patience, documentation, and a willingness to work within constraints that are not always explained upfront. It is a different skill to solo freelance work, and not every developer is equally comfortable with it.

Performance is a deliberate discipline, not a side effect

A Craft site that is slow usually has identifiable causes: unoptimised queries, missing caching, large uncompressed images, or render-blocking assets. Diagnosing and fixing these requires knowing how to read profiling data, how Craft's caching layers work, and how the browser processes a page load. Core Web Vitals now directly affect search rankings, which means performance decisions have commercial consequences.

A developer who understands performance does not just build fast sites by accident. They make deliberate choices throughout the build: how queries are structured, how assets are delivered, and how the cache is invalidated. A less experienced developer would not think to make them.

The tooling a developer pays for themselves

Behind every project there is a layer of tooling the client rarely thinks about. Version control hosting, local development environments, deployment tools, security scanning, error monitoring, database management clients, code editors, and the time spent keeping them all configured and current. A professional developer absorbs these costs as part of running a practice. They do not disappear from the work. They just do not appear as a line item on an invoice.

Experience compounds in ways that hours do not

The most useful thing an experienced Craft CMS developer brings is pattern recognition. They have seen what happens when a Matrix field is overloaded, when a site outgrows shared hosting, when a plugin update breaks a custom template, or when a content model that seemed logical at the start becomes an obstacle six months in. That accumulated experience shortens the time it takes to diagnose problems and make sound decisions under pressure.

It is the reason two developers can look at the same problem and arrive at very different solutions, and why the hourly rate of the more experienced one often produces a lower total cost.

If you are evaluating Craft CMS for a project, the comparison between WordPress, Craft CMS and Statamic covers where Craft fits relative to the alternatives. If you already have a Craft site and are thinking about what ongoing support should look like, what maintenance actually includes is worth reading alongside this. Or if you want to discuss a specific project, you can find out more about how I work with Craft CMS.