Why does your WordPress theme get harder to change every year?

Sage is not a finished design with a settings panel, it is a clean base you write a custom theme on. It gives the project a folder structure where it is obvious what is a template, what is a component, what is styling and what is logic. Dependencies are handled with Composer, so libraries do not end up hand-copied into the repository. The frontend is compiled with a modern build, which means smaller CSS and JavaScript than a general-purpose theme that loads everything for every possible case. For a client the important part is that the result is standard and readable to a developer who did not write it.

• A clear hierarchy of templates and components
• Composer instead of hand-copied libraries
• A frontend build with a much smaller output
• A structure every Roots developer already knows

Blade is the templating language known from Laravel. Instead of alternating PHP tags with HTML, you write short readable syntax: layout inheritance, sections, conditions, loops and component includes. The template stays about what is displayed, and the logic that prepares the data lives outside it. Output is escaped automatically, which removes an entire class of security bugs caused by unescaped content. In practice it means a less experienced person can change wording or the order of sections without risking that the whole page breaks.

• Layout inheritance instead of copied headers
• Readable conditions and loops inside the template
• Automatic output escaping
• Logic separated from presentation

A product card, a testimonial box, a call-to-action section or a pricing table is written once as a component in Sage and then simply used with different data. When the card needs to look different, one file changes and the change appears everywhere. That is the biggest difference from a page builder, where the same blocks are assembled by hand on every page and quietly drift apart over time. Components also work as design documentation: the project contains a list of building blocks a new page can be assembled from without inventing anything.

• One change applies across every page
• Identical elements actually stay identical
• New pages are assembled from existing blocks
• Less code to maintain with every new request

Sage does not conflict with content management. Custom fields through ACF, native Gutenberg blocks and custom blocks can all be rendered through Blade templates, so the editor works in the familiar admin while the code stays in one place. A page builder can stay for campaign pages, but I recommend keeping the core of the site in components, where a change has a predictable reach. When rebuilding an existing site I always start by finding out who actually edits the content and which parts they must be able to change without a developer.

• ACF fields rendered through Blade components
• Custom Gutenberg blocks with their own template
• Editors work in the normal WordPress admin
• A page builder only where it genuinely helps

Sage makes sense for sites that will keep growing: company websites with several page types, content projects, WooCommerce stores with a custom design and any project where another developer is expected to join. For a one-off micro-site with three sections it is unnecessary overhead and a simpler theme is enough. There is no lock-in either: the result is a standard WordPress site, just with a properly written theme. I work at 40 EUR per hour including VAT and a custom Sage theme typically lands between 20 and 45 hours.

• Right for sites that will keep growing
• Overkill for a one-off micro-site
• No dependency on a single supplier
• Roughly 20 to 45 hours at 40 EUR per hour including VAT