Avoca Web Design (my web design business) is 9 months into a transition into Statamic as our main platform of choice for building new websites. We’ve been a WordPress based business for 15+ years so there’s some inertia to overcome. However, we now launched a couple of Statamic websites into the wild and are working on half a dozen more.
I thought it would be interesting to take a look at what’s working well for us as our knowledge of the content management system (CMS) has deepened and we’re tackling bigger site builds with more complex requirements.
Some significant barriers have been broken down in the learning process and some helpful patterns are emerging. Let’s look at some of my key takeaways.
1. WordPress really is old and ‘crufty’
WordPress has served both us and our clients well for many years. However, this transition has shone a light on all it’s dark and dusty corners.
I’m now convinced that WordPress is incapable of addressing core issues in the long term and it’s never catching up with any of the modern platforms. The reason for that is two fold. Leadership focused on the wrong issues (see the recent issues in the community) and long term technical debt.
Every day we switch between working on Statamic sites and WordPress ones that we’re still preparing for launch or maintaining. Every single WordPress site I log into now causes me to bang my head on the desk at some point in interacting with it. To summarise the core issue, WordPress’ core is very old and not getting much attention from the WordPress development team. WordPress’ development efforts are focused on the Gutenberg editor and competing with Squarespace and Wix. However, they seem to be completely ignoring the broader experience of working with the platform. They are also not at all focused on those of us building sites for clients.
When you actually use a modern CMS tool that loads fast, is designed to be friendly for both content editors and developers, it’s a light bulb moment and you can’t unsee the shortcomings.
Key areas where Statamic is light years ahead:
No database, just flat files + GIT. That means all your content is always backed up and your local copy of the site is always up to date.
Image handling. I can’t overstate how flexible and modern Statamic’s approach to image management is. The actual implications are too many to dive into. However to pick a few; easily replaceable images, folders built in, ability to host images in S3 compatible storage, client editable focus points and easy image optimisation with glide.
Separating content and design. Content editors have a simple, fast and consistent editing experience throughout the site
Ability to customise practically any aspect of the website frontend or CMS backend without a million plugins.
Real time collaboration in the editor
Completely developer friendly, composer based, easy updates and version management of packages
WordPress realities I’m happy to leave behind:
Updates are constant and essential for security. The amount of time we spend on updates is ever increasing, when I look at our time tracking it’s nearly doubled in the last couple of years while the number of sites we manage has stayed the same.
Needs more than one content creation editing interface for both devs and clients for truely functional websites.
The admin interface is old and at times very slooooow
Massive, bloated site sizes that fill up our servers. Driven by ever expanding databases, poor image handling that generates many different sized images for each upload and the sheer volume of plugins required to run a site well. WordPress sites are very much larger than an equivalent Statamic site
Plugins “fighting” with each other and having unexpected interactions that require multiple support tickets with different support teams
WordPress realities that I still miss in the Statamic world:
The form plugins available in WordPress are fantastically powerful. As of the time of writing forms are due for an overhaul in Statamic 6, but currently lack a lot of the power user features without a lot of custom coding.
The sheer amount of plugins available. If you need something, chances are there is a plugin that will solve your challenge.
The collective knowledge and popularity of the platform mean that it is easier to find answers to questions or reliable contract help sometimes in New Zealand where we’re far away from other markets and timezones.
2. Don’t put all your eggs in one basket
One of the biggest takeaways is using the right tool for the right job.
If you need a website use a good CMS. If you need donations then consider a great donations platform that you can embed in the website. If you need ecommerce, use a purpose built tool like Shopify.
We were already doing this our design projects. However, after a few months of looking at what’s possible and starting to migrate WordPress websites away from WordPress, have highlighted the advantages of having a modular approach. Donations are able to be moved between websites seamlessly if they use an external donations platform. Another benefit in that scenario is that donation campaign managers and finance team members don’t need access to the website just to look at donations. That means less people in the organisation that need to interact with (and could break) the website.
A lot of WordPress developers are keen to squeeze every available function into WordPress to save on costs. However, the results are ALWAYS sub par in our experience compared to dedicated systems. There will sometimes be a few extra platform costs by using external tools for each task, but the time savings across the organisation are worth every penny.
Moving to Statamic has underscored all those thoughts for me.
3. The power of partials (true components)
Most “modern” website design tools have some flavour of components, reusable design blocks that you can easily change the style of sitewide but can make each instance unique from a content standpoint.
Many of the WordPress page builders have such tools now and they do make life easier. However, Statamic truely knocks this right out of the park (and over the road and right through the next field) with their partials.
Statamic has a really simple structure to reference a partial. Just put in your antlers partial tag with the location of the partial and it will be automatically included in the output. Here’s their docs on partials: https://statamic.dev/tags/partial
<div class="some-block">
{{ partial:foldername/partialname }}
</divEach Statamic partial can in turn include it’s own nested partials. This makes reusability a breeze and keeps your code and templates really DRY and readable.
You can easily pass data into a partial from your current context, assuming you have setup the partial to accept variables. The example below would set the heading in the partial output to “This is cool” and the variable “somevariable” to the output of the field “fieldname” from your current context (e.g. from a field in your page builder block).
{{ partial:foldername/partialname heading="This is cool" :somevariable="fieldname" }} It’s probably really obvious by now, but that let’s you have partials that control all sorts of common things like buttons that you can call and use with unique values that you either pass data to or hardcode depending on your needs.
This infinitely nestable structure and the ability to pass data and styles into a partial easily makes them super powerful. When you combine that with the power of Statamics fieldsets and particularly the replicator and bard fields you can build some amazingly flexible and yet easy to manage content.
I can’t really imagine how this level of flexibility and power could be achieved in a visual UI. It certainly wouldn’t be easy. The end result is that you can make controls that you expose to the client for editing that can do anything from control a heading to completely change the layout of a block or section. All while having the output logic in a much easier to manage code file and not in some complex visual UI and hidden behind popup or context menus.
4. Understanding where and how utilise fieldsets for maximum reusability
It took me a while to fully understand that as well as using partials to make your code easy and reusable, you can use fieldsets in the same way. In WordPress the field tools like ACF don’t let you save fieldsets that can be imported into multiple other places so you’re always building fields from scratch. That was a habit I had to unlearn. I’m so delighted with the more modular, flexible approach Statamic takes for this feature.
With a bit of planning, you can make a bunch of common field sets that you can reuse in multiple places for consistency and updatability.
Some good common examples would be:
Different bard fields saved for different editing modes
Full articles with lots of sets and full text controls
Basic text editing with limited controls
Heading / hero fields to include at the top of different collection blueprints so they are consistent and you can use the same partial to display the output
Buttons
The end result is a “common” language throughout the CMS. Every time you edit a button, it’s the same experience. I know that sounds like it should be true but it’s not with WordPress, Gutenburg does buttons this way, Bricks builder has a different UI and then if you’re using ACF for some custom content then you’ll likely have a third way of doing it.
It also makes the design process easier as you just reuse the same partials throughout your design. Have a button using your buttons fieldset somewhere in the backend? Great, just put {{ partial:component/buttons }} in your template and you are good to go.
Clients that we are training are really impressed with how easy and consistent the Statamic interface is. This is one of the primary reasons in my opinion.
5. Starter Kits, not themes and the power of Peak
Statamic uses “Starter Kits” as a kick off point for projects. Similar to WordPress themes in that they power the look and feel of the front end, they are also very different. A starter kit is just that, a start point. Some are very polished or have a specific purpose such as the foundation of a documentation site. However, they are not really meant to get updates. You are supposed to customise the heck out of them to get YOUR site and therefore they are not constant source of updates like themes on the WordPress side of things.
We gravitated to the Peak starter kit by Rob at Studio 1902. It has some great features that really work for our design process. We love the fluid grid, a CSS grid for consistent layouts. We use something very similar in our WordPress sites and so it was a natural fit for us.
Here are some of the features that I love in Peak
Fluid grid
Peak Commands - a powerful set of tools, presets and - paid but worth every penny
Built in SEO
Dependable and flexible buttons
Page builder framework
The main starter kit is free and is a labour of love from Rob and a great gift to the community. Having built custom blueprint setups in WordPress and then seen how polished Peak is, I get an idea of just how much work has gone into it.
I love the idea that you’re not constantly living in fear of a theme update arriving that breaks a site design because the theme developer suddenly decided to change fundamental CSS output that you relied on
6. Cursor and using AI to supercharge productivity
I know that some people will have opinions, perhaps even very strong ones on this topic. Cards on the table, we’re not into “vibe coding”. However, switching to a code focused design flow including tailwind has allowed us to really explore using AI coding tools like Cursor and Claude Code to work alongside our team.
We’re finding it extremely helpful and productivity boosting to not have to look up documentation every time and to ask for help from a tool that is fully integrated in our development environment and can see our actual code context. Don’t get me wrong, you still need to know/learn how Statamic works and there’s no substitute for that. You still need to prompt engineer a lot to get great results. However, we’re doing more and getting more work done than we would be coding it all manually.
This kind of full access to the code base and content is only possible with a flat file CMS that is running locally. Even if you have a WordPress theme build process your code tools are not context aware of all the fields and content in the database. While it’s inevitable that some kind of AI integration will come to WordPress and page builders of all stripes, I don’t think it will be as flexible as something like Statamic where the entire site is an “open book”.
I’m increasing switching to Claude Code as well. I love that it’s available in any code editor I want to use.
