The question that decides the build
Every custom WordPress build for a client answers one question early, usually without saying it aloud: how much freedom does the editor get? Too little and every change comes back to you. Too much and the site drifts off its design within a month, because a blank canvas is an invitation.
The two mainstream answers are Advanced Custom Fields, where the editor fills in named fields and the theme decides how they render, and native blocks, where the editor composes the page from components in the block editor. Both are mature. Both are defensible. The wrong choice is picking one on principle rather than on the client.
What ACF is good at
ACF gives the editor a form. A treatment page has a title field, a from-price field, a duration field, a gallery field and a body. The editor cannot move the price above the title, cannot make it purple, cannot forget the duration because the field is required. The template renders the same way for every treatment, which is exactly what you want for the fifty-treatment dental site or the twenty-practitioner clinic.
Where ACF wins:
- Structured, repeated content. Services, team members, locations, price lists, opening hours. Anything that is a record rather than a document.
- Content that other systems read. If the price lives in a field, the schema markup, the booking widget and the comparison table all read the same value. If it lives in a paragraph block, nothing can.
- Editors who want a form, not a canvas. Reception staff updating a price list want a field labelled "Price". They do not want to find the right block.
- Design integrity over years. The theme owns the layout. The editor cannot break it.
Where ACF costs you: long-form pages with varied layouts become a fight. Either you build a flexible-content field that approximates a page builder badly, or the editor ends up in a single WYSIWYG field with no structure at all.
What native blocks are good at
Native blocks give the editor a canvas with guard rails. With theme.json, block locking, patterns and a curated block list, the canvas can be far more constrained than its reputation suggests, and the editing experience is the one WordPress itself invests in.
Where blocks win:
- Long-form and marketing pages. The about page, a landing page, a case study. Content whose shape varies page to page.
- Editors who write. A marketing manager composing a page wants to move a quote above an image. Blocks let them, within the patterns you allow.
- Patterns as reusable design. A "treatment intro" pattern with locked structure gives most of ACF's consistency with block-editor ergonomics, and pattern overrides in recent WordPress versions let you fix parts of it globally.
- Future-proofing. Blocks are where the platform is going. Block themes, the site editor and the styles system all assume them.
Where blocks cost you: structured data. A price in a paragraph block is text. Reading it from anywhere else means parsing HTML, which is how sites end up with a price on the page that disagrees with the price in the booking widget.
The framework we use
Ask three questions about each kind of content on the site.
Is it a record or a document? Records, things with the same fields every time, go in ACF on a custom post type. Documents, pages whose structure varies, go in blocks.
Does anything else need to read it? If the value feeds schema, a widget, a feed or another page, it is a field. Always.
Who edits it, and how often? Front-desk staff editing weekly want fields. A marketing person editing monthly is fine with blocks. If the same person does both, give them fields for the records and blocks for the pages, and label the difference.
That produces the hybrid nearly every serious build ends up with: ACF-backed custom post types for services, team, locations and prices, rendered by templates; native blocks for the pages that are written rather than filled in; and ACF blocks, where a block's fields are ACF fields, for the handful of components that need both a canvas position and structured data, like a pricing table or a booking call-to-action.
Three mistakes to avoid
Flexible content as a page builder. An ACF flexible-content field with fifteen layout types is a worse block editor. If you find yourself building one, the content is a document and belongs in blocks.
Unlocked blocks on templated pages. A treatment page built from blocks with nothing locked will be twenty different layouts within a year. Lock the pattern or use fields.
Storing structured data in block attributes and hoping. Block attributes are serialised into post content as HTML comments. They are readable, but fragile, and no plugin ecosystem treats them as a data source. If it matters to another system, it is a meta field.
Cost and licensing
ACF Pro is a paid licence, and it should be bought in the client's name so it renews with the site and not with you. Native blocks are free. That difference is real but small next to the cost of the wrong architecture, and a hybrid uses both anyway.
What we deliver
For booking-led business sites, the default is the hybrid above: records in fields, pages in blocks, and a short recorded walkthrough showing the client which is which. For agency work where the client has their own editorial team, we lean further into blocks with tight theme.json constraints and patterns. Either way, the test at handover is the same: can the client change a price, add a person, and write a page without calling anyone, and does the design survive them doing it.
If you are scoping a WordPress build and want a second opinion on the content model, that is a conversation we are happy to have, fixed price and all.