The framework behind our work is now open source. See how we're evolving CHISEL, the tool we use every day.
Every WordPress project used to start the same way, by rebuilding the same foundation you'd already put together a dozen times. You'd sit down to make something and spend the first morning fighting a build config instead. By the time it finally worked, half the day was gone and the actual site was still a blank page.
The lost hours were bad enough, but the real problem showed up across a whole team. Everyone set things up a little differently, so no two projects looked alike, and moving between them meant relearning where everything lived. We tried the starter themes around at the time, but they either didn't fit how we work or were so complex they made more work than they saved. Which ones exactly is a blur a decade later, but the takeaway stuck, so we built our own: one shared structure, one set of conventions, and a real starting point instead of an empty folder, so a developer's time goes into what the client is actually paying for. We called it Chisel.
It's open source now, the framework we build on at xfive and use well beyond our own team, while still evolving.
What ten years taught us
Most of what stuck over ten years had less to do with WordPress itself and more to do with how teams work and how software ages.
Developers who've built on the same foundation dozens of times stop thinking about it.
It's the same folder structure, the same Twig components, the same way styles and blocks get wired up on every project. Nothing moves between builds, so nobody stops to relearn it, and a new developer is productive in days because the second project looks exactly like the first.
Every new project used to reopen the same old argument about naming and structure.
We settled naming, file structure, the patterns for the problems that recur on every build, and the coding standards every developer inherits once, at the framework level, and let tooling hold the line. Linters and a pre-commit hook keep every project looking the same no matter who wrote it, so no one relitigates class names or folder layout at the start of a job, and once those things are right, they stay right.
Chisel is ours, top to bottom.
The whole framework rests on a single runtime dependency: Timber. An abandoned plugin can't dictate our roadmap, and when WordPress moved to blocks, we could rebuild the entire rendering layer ourselves instead of waiting on someone else to do it (more on that below). Clients get a consistent product built on something we actively develop and have no intention of dropping.
The work is never finished, and what "keeping up" means keeps changing.
Ten years ago, keeping pace meant a proper build step and a sane way to write CSS. Then it meant rebuilding around the block editor. Lately it's meant giving Chisel its own layer for AI-assisted development. A tool that stops moving eventually becomes the thing everyone has to work around. Chisel has never been "done," and after ten years we've stopped expecting it to be.
Chisel is a modern WordPress development framework, available as an npm package.
From a single command it scaffolds a complete project (a Timber-based starter theme, a modern build pipeline, and our coding standards) so you're building features on day one rather than assembling a foundation.
We use Timber and Twig to keep logic and presentation apart, so templates don't become a tangle of HTML and PHP. A template ends up being just the markup and the data it's handed:
{# views/components/post-item.twig #}
<article class="post-item">
<h2 class="post-item__title">{{ post.title }}</h2>
<div class="post-item__excerpt">{{ post.preview }}</div>
<a class="post-item__link" href="{{ post.link }}">Read more</a>
</article>The logic that prepares post lives in PHP, well away from the presentation.
On the CSS side, styles are organized with ITCSS (Inverted Triangle CSS) and paired with modern Sass features like @use and @forward. theme.json is where the design tokens live. Colors, spacing, and font sizes are defined once, and Sass helpers like get-margin('large') or get-font-size('small') read straight from it, so values aren't duplicated between the editor config and your stylesheets, and a token can't drift out of sync unnoticed.
The build is a hybrid setup that combines a custom Webpack configuration with the official @wordpress/scripts package: JS and SCSS bundling with hot reload, linting for both, hashed and revisioned static assets, and React support out of the box. The whole thing is Docker-ready, so a new developer can spin up a consistent local environment without a day of setup.
A lot of WordPress work is repetitive plumbing, and Chisel handles most of it for you:
- Auto-registration of blocks, both native and ACF, as well as custom post types, ACF options pages, and assets and scripts.
- A sync watcher for ACF field groups, with the developer confirming changes rather than having them applied without warning.
- REST API endpoints for AJAX requests, so async calls don't have to go through the heavier, older wp_ajax path, plus fetch helpers to make those calls simple.
- Ready-made components, utility and helper functions, and custom action and filter hooks you can build on.
- Base integrations for the plugins we reach for constantly, like Yoast, WPML, and Gravity Forms, plus WooCommerce support and starter scripts like Swiper already configured.
None of these is exotic. They're the things every project needs, done right and consistently every time.
Moving with WordPress, not against it
Chisel's biggest architectural bet is to move in the same direction as WordPress rather than carve out a separate path. It uses current WordPress versions, embraces block-based building, and supports both native and ACF blocks. When WordPress evolves, Chisel follows, which keeps it relevant instead of slowly drifting into a private dialect only we understand.
That commitment isn't free. At one point, we had to substantially rebuild Chisel to fit where WordPress had gone, the effort we now call Chisel 2.
There's a shrine in Japan, Ise Jingū, torn down and rebuilt every twenty years on purpose, so the craft passes to new carpenters instead of dying with the old ones. We didn't plan Chisel 2 that way, but it had the same effect. The people running the framework now aren't the people who wrote it, and rebuilding the rendering layer is how they actually learned it.
Early on, Chisel had the same weakness as most starter themes. Once you generated a project, its foundation was frozen, and later improvements to the framework never reached the sites already built on it. The Chisel 2 rebuild fixed that too, introducing a two-tier structure that keeps the core separate from your project layer. Pre-commit hooks guard core files against accidental edits, so you can update an existing project to a newer version without clobbering your customizations, and because the codebase is object-oriented, extending it is straightforward rather than a fight.
Chisel isn't a full site editing (FSE) theme, and that's a deliberate choice.
It takes a hybrid approach, borrowing the parts of the block era that genuinely help, like theme.json as the single source of truth for design tokens, block patterns, and the block editor for managing content, but stopping short of handing the whole site over to the Site Editor. The line falls between structure and content. The templates FSE would otherwise let you edit in the Site Editor stay in structured Twig, under developer control, so the design keeps its shape. The content itself, across pages, posts, and custom post types, is built with blocks that editors can add and rearrange freely.
That comes straight from experience. Most client projects don't need full FSE. They need a content area that's clear and intuitive to manage, templates that match the delivered designs exactly, and a setup that's hard to break by accident. Full site editing trades that control for a kind of flexibility most clients never use, and that flexibility is often where a design drifts out of spec without anyone noticing. So Chisel keeps the predictability for now, and full FSE support sits on our roadmap as a switch we'll be able to flip when a project genuinely calls for it.
Where Chisel goes next
That same philosophy is why Chisel is now the foundation for our work with AI coding agents. We've built an AI toolkit on top of it that teaches an agent our conventions and keeps a developer in the loop. But that's a story for another article.
Chisel is still our starting point for building fast, maintainable WordPress sites, sharpened by every project we run through it and by the more than ten people who have shaped it over the years. That mix of hands, a decade of accumulated, argued-over experience rather than one person's preferences, is part of what makes it trustworthy. And it's open source, so anyone can use it, not just us. Browse it, fork it, and if you like it, a star on GitHub is always welcome.
About the author
