WordPress still runs a large share of the web, so a lot of redesign work ends with the same question: we have the design, how does it become a WordPress site that people can actually edit? There are three honest routes, they produce very different sites, and the choice matters more than any styling decision that follows it.
Three routes, and what each really costs
A custom theme built from the design. Fastest possible output, complete control of the markup, no third party page builder in the stack. Editors get exactly the blocks you decide to give them, which is either discipline or a straitjacket depending on how well the fields were planned. Needs a developer for structural change.
Native blocks with a block theme and custom block patterns. The middle path, and the direction WordPress itself is going. Editors compose pages from patterns you designed, so new pages stay on brand without a developer. Requires more setup work to constrain what is possible, because an unconstrained block editor lets anyone build a page that looks nothing like the design.
A page builder such as Elementor or similar. Fastest to launch, most familiar to non technical teams, and by far the heaviest. Expect more markup, more scripts, and slower pages, plus a dependency you cannot easily leave: a site built in one builder is genuinely hard to move to anything else later.
For a business that publishes regularly and wants speed, a custom or block theme is usually right. For a small team that needs to rearrange pages themselves and does not care about milliseconds, a builder is defensible. What is rarely right is a premium multipurpose theme plus a builder plus twenty plugins, which is how sites become unmaintainable and insecure.
Translate the design into fields, not pages
The step that separates a professional build from a template job happens before any CSS: deciding what parts of each page are content and what parts are design.
Go through the Figma file and mark every element an editor should be able to change. A hero headline, a list of service cards, a testimonial, a case study’s client and industry. Those become custom fields and block patterns with real constraints, so an editor can change the words without being able to break the layout.
Everything else stays in the template, where it belongs. The failure mode on both extremes is familiar: hardcode too much and every small change becomes a developer ticket; expose too much and the site drifts away from the design within a quarter.
Model the content types properly while you are here, since custom post types for case studies, services, and team members are far easier to define now than to retrofit later. It is the same modelling exercise as deciding whether you need a headless setup at all.
Build the system, then the pages
Set global typography, colour, and spacing once, from the design’s styles, and use those tokens everywhere rather than styling each section independently. Build the repeated components (buttons, cards, section wrappers) as reusable patterns.
The same rules apply as anywhere else: responsive behaviour is designed in the browser because Figma cannot describe every width, semantic heading order is set by hand, and every state that is not the resting state has to be built.
Performance is a WordPress problem worth solving deliberately
A WordPress site is fast or slow depending almost entirely on choices made during the build, not on WordPress itself.
Keep plugins to the ones you genuinely need, and audit what each one loads on every page (the worst offenders enqueue their scripts sitewide for one feature on one page). Serve images in modern formats at real dimensions with lazy loading. Load only the font weights used. Add page caching and a CDN. Defer or remove render blocking scripts.
Done properly the result passes Core Web Vitals comfortably. Done carelessly, no amount of caching rescues a homepage carrying a slider plugin, four fonts, and an unoptimised hero.
The parts that get forgotten
Set metadata per template and per post type, not just on the homepage, and make sure the editor can override it. Add structured data for the content types that support it. Build a real 404 page and search results page, since both exist whether you design them or not.
Harden the install: unique admin credentials, two factor, removal of unused themes and plugins, and a real backup routine, because an outdated plugin is the most common way business sites get compromised.
And if this is a redesign rather than a new site, the URL map is the whole ballgame. WordPress permalink structures change easily and silently, so every old URL needs a mapped destination before launch.
Then hand it over properly
The build is not finished when it looks right. It is finished when someone on the client’s team can add a case study without calling you: a short recording of how to publish, the field names in plain language, and constraints tight enough that they cannot accidentally break the design.
That handover is what makes a redesign last, and it is the same standard a developer handoff deserves.
Have a design and an existing WordPress site to replace? hello@beconfidency.agency.
If you want the design, the build, and the migration owned by one team, that is exactly what our web development service is for.