One of the most important decisions in a custom WordPress project is not which animation library to use or how the hero should look. It is deciding what belongs to the theme and what belongs to the editor.
The theme should protect the system
Layout, spacing, typography, responsive behavior, component states and accessibility patterns are system decisions. When these controls are exposed everywhere, a website becomes easy to edit but equally easy to damage. A custom theme can keep those rules in code while still giving editors meaningful control over the information customers actually need.
ACF should expose content, not visual chaos
Structured fields are useful when they represent real editorial choices: a heading, introduction, CTA, service relationship, testimonial, FAQ, image or metric. They become less useful when every margin, color and corner radius becomes a field. That recreates a page builder with more maintenance and less predictability.
Reusable content should have a reusable model
Services, case studies, industries and testimonials usually deserve structured content types because the same information appears in multiple places. Global contact information belongs in theme settings. Archive introductions belong in archive settings. Page-specific narrative belongs with the page. This separation keeps the admin understandable as the site grows.
Performance benefits follow the architecture
When templates know exactly what they need to render, the frontend can avoid unnecessary libraries and page-builder markup. Assets can be loaded deliberately, image dimensions can be controlled, and the HTML hierarchy stays easier to audit for search and accessibility.
The useful test
Ask one question for every proposed field: should an editor be able to change this without a developer because the business meaning may change? If yes, expose it. If changing it would alter the design system or create inconsistent behavior, keep it in code.
That boundary is what makes a custom WordPress theme both editable and durable.