By Cristian Daron
The sites I build usually outlive my involvement in them, and somebody else has to edit them. That one fact decides most of how I build a WordPress theme.
Blocks the client's team can use
I build custom themes around custom Gutenberg blocks, usually with ACF: a block for each kind of section the site needs, with the fields an editor should change and nothing they should not. The team gets pages that are easy to update and hard to break, which is what an editor actually wants from a CMS.
Why not a page builder
Page builders such as Elementor and Divi make the first build quick and many later changes slower. Layout, content and styling end up tangled together in one editor, the markup grows heavy, and performance pays for it. I prefer custom blocks for maintainability and speed. If a page builder is already your stack I can work with it, and I will tell you upfront if it is going to work against your performance goals.
Content modelled properly
Blocks are half of it. The other half is modelling the content: custom post types for the things a site actually has, with fields for the parts that repeat. Get that right and the templates stay simple.
Plugins for what a theme should not carry
Features that are not presentation belong in a plugin, not the theme. Integrations with outside services, custom data and anything that should survive a redesign live in custom plugins, so a new theme does not mean rebuilding the business logic.
Taking over an existing site
Most WordPress work is not a fresh build. When I take over an existing theme or plugin, I review its structure first, document what is there, and then extend or refactor it without breaking what already works.