Development
Why we build on ACF and not Gutenberg blocks for everything
Gutenberg is the future. That doesn't make it the tool.
The future of the platform and the right tool for a site a marketing team lives inside for five years are two different questions. Most studios mash them into one. We don't.
Build with Gutenberg blocks and the content and the markup fuse. WordPress saves the actual HTML into the database and validates it character by character on every load. Change a wrapper div six months later and every existing instance of that block breaks. The platform's answer is deprecations: write the old markup, teach the editor to migrate forward, and pray you miss none.
Miss one, and an editor opens a page to fix a phone number and finds a broken block on something she never touched.
The whole fork: same object, or two.
Fused (Gutenberg): content and markup are the same object. Improving one breaks the other. That's not a bug. It's a choice made at build time, and the editor pays for it.
Separated (ACF): a hero is a headline, a subhead, an image ID, a link. Structured data in one table, completely separate from how it renders. The two were never welded, so neither can break the other. It's the same separation argument behind why we stopped using page builders.
The template lives in a PHP file in version control. Need that extra wrapper div six months on? Edit one file. Every page updates instantly. The editor never sees a warning.
Separation is the difference between a site you confidently hand to a marketing lead and one that quietly stacks landmines every time a developer improves a component. One you leave. The other you babysit.
Separation is the difference between a site you confidently hand to a marketing lead and one that quietly stacks landmines every time a developer improves a component.
The honest cost, said out loud.
ACF isn't free of tradeoffs. Editors get a less visual experience: they fill in fields, not a live canvas. Gutenberg's in-place editing is genuinely nicer to use, and we won't pretend otherwise. ACF Pro is also a paid plugin with an annual license, and we carry that so you don't inherit a coupling problem to save a line item.
On simpler content sites where the layout vocabulary is basically what core already gives you, no repeating branded components, no five-year maintenance story, we reach for blocks.
The honest position isn't ACF always. It's that the moment a site has structured, repeating, branded components a team will maintain over years, coupling that content to its own markup is a trap. So we ask one thing on every project: who edits this in two years, and what happens to their content the day we improve the component they're using?
The question we ask on every project.
Who edits this in two years, and what happens to their content the day we improve the component they're using? Coupling structured, repeating, branded content to its own markup is a trap the moment a team lives inside a site for years.
If you're not sure which side of that fork your own site landed on, that's worth checking before the next redesign gets scoped. The redesign readiness scorecard walks through exactly that.
One you leave. The other you babysit. That's the whole choice, made once, at the start, instead of paid for slowly over years.