Your template. Your Figma.
Our discipline in the middle.
Agencies with branded WordPress template systems don’t need a dev team that improvises. They need one that maps Figma to template faithfully, runs QA until the design matches, and never touches the shared components the next client’s site depends on. That’s the work we do.
Template customisation is not a shortcut.
When an agency delivers us a Figma and access to their branded WordPress template system, the work is not “install theme, fill in content”. It is a page-by-page reconciliation of two design systems — the agency’s template defaults and the client’s approved Figma — with a QA loop that runs until every breakpoint on every page matches.
We work exclusively within per-client overrides. The shared template components that serve every other site on the agency’s roster remain untouched. That distinction matters: a customisation that leaks into a shared component does not show up in this project’s QA pass — it shows up weeks later on a different client’s site.
This is what separates a templated build from a greenfield custom build: the starting point is the agency’s existing template system, not a blank canvas. And it separates it from a rebuild: there is no platform migration, no redirect map, no legacy URL archaeology. The scope is focused — take the Figma, apply it faithfully to the template, iterate through QA until the agency signs off.
The buyer for this service is a marketing or SEO agency that runs its own branded WordPress template system and needs a subcontractor that can be trusted with their template investment. We are not visible to the end client. The agency’s design, hosting, content direction, and client relationship all stay upstream of us.
A Build constructs pages and templates from your Figma library on a blank URL space — your design system, built from scratch. A Templated engagement starts inside an existing branded template system and customises against it per-client, without forking the shared library.
A Rebuild migrates an existing site line-for-line: redirect map, meta-tag spec, legacy URL preservation. A Templated engagement has no platform migration, no redirect work, no legacy archaeology — just the Figma against the agency’s template, page by page.
-
01
Figma-as-contract, template-as-canvas
The agency’s Figma file is the design specification. The branded template is the underlying page structure. We reconcile the two page by page — where the template defaults match the Figma, we keep them; where the Figma requires a deviation, we customise. No design decisions originate on our side.
-
02
QA cycle at template-customisation scale
A clean template customisation is not “build once, review once”. It is build, QA, adjust, QA, adjust — as many rounds as the design demands. The QA loop is where the value is delivered on a templated project; a shorter loop is a weaker match to the Figma, not a faster delivery.
-
03
Customisation without drift
Every change — layout deviation, component override, style token adjustment — is documented against the Figma reference and applied strictly to per-client scope. The agency’s shared template components are not modified; the next site built on the same template inherits no side effects from this project.
-
04
Pre-handoff QA via Site Checker
Before handoff, our own Site Checker plugin runs across the staging environment: core settings, content and SEO surface, URL structure, content-language sanitisation across pages, posts, Elementor data, menus, and widgets. Fail-zero gate before anything goes to the agency.
-
05
Agency-side review and fix loop
Post-handoff, the agency runs their own AutoQA pass — Links, Email, Content AI, and sometimes a visual audit — and surfaces findings into the shared issue backlog. We work the backlog until the agency signs off. That process is theirs; we own our response time.
-
06
Cross-device verification
Every QA round covers the affected pages across desktop, tablet, and mobile viewports — Chrome as the primary engine plus the agency’s nominated cross-browser checks where the brief calls for them. Coverage is scoped to the round’s design deltas, not the full site, which keeps the cycle efficient without losing breakpoint discipline.
- Page count 15 – 100 customised URLs for most engagements; multi-location and large-blog sites can run higher
- Templates applied 8 – 12 reusable agency templates, all mapped against per-page Figma
- QA volume 100 – 400+ tracked SEO + CX issues reconciled across the agency’s launch checklist
- Timeline 30 – 180 days for typical engagements — longer QA tail than a rebuild; driven by agency sign-off cadence; complex multi-stakeholder projects can extend further
- Effort 15 – 120 hours: development + QA iterations + project management
- Team 3 – 7 specialists — lead developer, QA developer, PM, plus additional dev or QA support on high-iteration rounds
- Hosting Kinsta, WP Engine, or the agency’s standardised stack — we deploy to their environment
- Staging URL Inside one week of project start; on the agency’s hosting account, not ours
- Visibility Zero to the end client. All communication runs through the agency’s shared workspace.
Customisations from the portfolio.
White-label engagements delivered for US marketing agencies running their own branded WordPress template system. End clients named with permission; partner agencies not named.
What determines the hours budget.
Templated budgets are set per project, not per hour. The Figma defines the design surface; the sitemap defines the page count; the agency’s QA cadence defines the iteration depth. Below are the levers that move the aggregate, drawn from real engagements.
20–35 customised URLs on a well-documented agency template, no service-taxonomy explosion, single design language across the sitemap. Two to three QA rounds typical before the agency’s sign-off.
40–55 URLs with a deep treatment matrix, multi-location routing on the template, and a full SEO + CX backlog reconciled across the agency’s launch checklist. The QA tail does the heavy lifting.
When the agency’s design lead requires more than three review-and-adjust cycles. Each extra round adds development plus full cross-device verification on the affected pages — the budget is honest about that, not absorbed.
Customisations land in per-client scope only. Shared template components are never modified, so the next site built on the same template inherits no side effects from this project — no surprise debugging on a different client weeks later.
Three to seven specialists per engagement, depending on page count, iteration depth, and QA volume. QA share is structurally higher than on a Build — a clean templated project may run 40–55% QA by hours because the value lives in matching the Figma at every breakpoint, not in bespoke construction. PM share scales with iteration count: high-iteration rounds need stakeholder coordination across the agency’s design lead, account manager, and client-experience track.
Frequently asked, plainly answered.
Specific to this engagement shape — what we mean by it, what we own, what changes the hours.
-
No. Per-client overrides stay in per-client overrides — your shared template components are not modified. The customisation lives in the child theme or page-builder template scoped to the single site; the shared system stays clean for every other client using it.
-
Figma file URLs are redacted from any public artefact we publish — case studies, talks, internal docs. Your agency's Figma structure, naming conventions, and component library stay proprietary. We work inside the file you share; we don't fork it, don't reference it externally, and don't carry its patterns into other clients' work.
-
Templated work is QA-heavy and Redmine-light. The bulk of activity lives in the agency's tracked backlogs — typically a SEO backlog tab and a CX/AM backlog tab in the workbook, often several hundred rows total. Redmine captures only dev-direct tickets; the QA closure work is logged on your side. We surface both volumes in reporting.
-
By default, yours. AutoQA is the agency-managed Stage 2 of QA — runs post-handoff, owned by your QA team. Our Stage 1 is Site Checker (core settings, content parity, multi-resolution capture) running pre-handoff. By agreement we can take Stage 2 on ourselves — but the cost scales proportionally to site volume (number of URLs, forms, phone numbers and email addresses the checks cover). Without that explicit agreement, the two layers don't overlap, and we don't claim Stage 2 work as ours.
-
It depends more on workbook scope than on service count alone. Two-service architectures require ladder-specific patient journeys, ladder-specific CTAs, and a doctor-pair template that single-service practices don't need — that's additional structural work. But in our published corpus the per-URL hour rate has been lower on multi-service projects than on single-service ones, because the extra template work is offset by shared QA patterns across ladders. The premium is scope-dependent rather than a fixed multiplier — we'll estimate from your workbook, not from service count.
Have a
template brief?
Send the Figma link, the sitemap, and which agency template system you’re on. Within 24 hours: a sharp set of clarifying questions and a fixed-hours estimate before any work starts. NDA on request before anything is shared.
Not sure if a Templated engagement is the right shape? Compare to a Build →
Brief a customisation