Your Figma File, Built as Maintainable WordPress

Type, spacing, colour and layout are implemented from the file rather than eyeballed from an export. The honest caveat is that a Figma frame is a fixed canvas and a website is not: text reflows at different lengths, real content is longer than placeholder content, and browsers render type slightly differently. Those are the points where a design has to make a decision, and we raise them with a recommendation instead of guessing.

Whichever fits who maintains the site. ACF with a custom theme suits content-heavy sites with a real editorial team and gives the most control over the editing experience. Gutenberg and block themes suit clients composing pages from a constrained set of components. Elementor suits teams already standardised on it. We recommend one and explain the trade-off in maintenance cost — and if you have already standardised on a stack, we build in yours.

We implement your frames as anchor points and make deliberate decisions for the widths between them — what reflows, what reorders, what is hidden, where a fixed size becomes fluid. Anything ambiguous comes back to you as a specific question with a recommendation. Layouts are checked between breakpoints rather than only at them, which is where most implementations quietly break.

View access to the Figma file, the fonts and their licences, and any content that exists. Well-organised files with components, styles and auto-layout make the build faster, but a messy file is not a blocker. What genuinely slows a project is missing states: no mobile frame for a key page, no empty state, no error state, no hover behaviour. We flag those during review so they are decided before they become a delay.

That is a design decision as much as a build one. Repeating elements become real content structures — team members, case studies, testimonials, pricing rows — edited through fields rather than page markup. Composable sections become reusable blocks or patterns. Sections that should not be edited are locked deliberately. Your client gets an editor matching how they work, and you get a handover document rather than a support call.

A plugin converts a frame into markup, quickly, and can genuinely save time on a simple layout. What it cannot do is decide how your client's content should be structured, because that depends on pages that do not exist yet. That judgement is most of the work. Automated output also tends to produce absolutely positioned layouts, inline styles and headers outside the theme's templating — correct in a demo, expensive at the first content update.

Both, though most agencies come to us with the design done and their own designer on the account — the arrangement we would expect. Where a file has gaps we can produce the missing frames and states in your design system rather than sending the project back. If you need the design work itself, we scope that as its own piece rather than folding it invisibly into a build quote.

Yes, white label as standard. NDA before the first file changes hands, no contact with your client, and your naming on staging URLs, documentation and repositories. You own the client relationship and price the project however your market supports. We invoice you; the two numbers are unrelated.