New sites, built from your brief. Not from a template we guessed at.
A Website Build means a blank canvas, your spec in a workbook, and a team that executes against it without reinventing your strategy. Figma to live. No drag-and-drop improvisation.
First-pass construction, done properly.
A WordPress Build starts where a spec ends. You hand us a sitemap with URLs, a Figma library or wireframes, a template catalogue. We fill the row-level hours estimate ourselves — that per-row budget becomes the contract. From there we build against the spec — templates registered, pages wired, plugins selected and configured, hosting environment set up — and we don’t make design decisions or write copy on your behalf. Every client-facing choice stays with you.
The build follows a two-stretch shape. The first stretch produces the templates and page structure. The second — running against staging through your QA backlogs — closes the gap between “pages exist” and “site the agency can hand to a client.” That second stretch is where internal links get reconciled, content polish lands, bugs from the QA loops get fixed, and both the developer backlog and the account-manager review track get worked down to zero open items before we touch a launch checklist.
Theme architecture, custom Gutenberg blocks or Elementor Pro, ACF field groups, Gravity Forms or SaaS booking embeds, WP Engine or Kinsta staging to live — the tooling flexes around your standard stack. What doesn’t flex: the workbook is the contract, the per-row Hours Estimated column is the budget, and “Phase 1 done” is never the end of the engagement.
A Rebuild replaces an existing site line-for-line: redirect map, meta-tag spec, legacy URL preservation. A Build starts from a blank URL space — no migration baseline, no “rankings to preserve”.
A Templated engagement customises a pre-made branded template per client. A Build constructs the pages and templates from your Figma library — your design system, your URL architecture, built from scratch.
-
01
Workbook intake and scope lock
We open your Google Sheets workbook — Sitemap, Templates, Checklist, QA backlogs — and lock scope before a line of code is written. Every sitemap row carries an Hours Estimated value; that row-level budget is the contract. We surface ambiguities at intake, not mid-build.
-
02
Template registration and environment setup
Staging environment provisioned on your hosting platform (WP Engine, Kinsta, or your VPS). Templates registered — one PHP file or Elementor template per template type in your library. Plugin stack installed and configured: SEO plugin, performance plugin, forms, booking embeds. No improvised additions.
-
03
First-pass page build against the sitemap
Every URL in the sitemap gets built against its assigned template and its per-row Hours Estimated value. Custom logic scoped to your project — typically ACF field groups, custom post types, taxonomies, menu structure, plugin integrations — is implemented in this stretch. All client-facing content decisions remain with the agency.
-
04
Pre-handoff QA through Site Checker
Before we open staging to your QA team, we run the build through Site Checker — a WordPress plugin we built and maintain — across core settings, content and SEO surface, URL structure, content-language sanitation, menus, widgets, and multi-resolution screenshot capture. Fail-zero gate. Warnings reviewed and judged non-blocking before handoff.
-
05
Parallel QA loops, worked down to zero
Two parallel backlogs run simultaneously: a developer-track backlog (implementation issues, template bugs, integration failures) and an account-manager or client-experience track (copy, layout, UX observations from your team's review). Both are worked down to zero open items before we touch the launch checklist. We do not launch with open developer-track items.
-
06
Launch checklist sign-off and handoff
Launch checklist items — spanning Design, Functionality, Pre-Launch, and Post-Launch columns — are signed off row by row. After checklist closure, the site is yours: staging is ready to promote to production, agency QA layer confirmed complete, no loose threads. We write no post-handoff copy and make no post-handoff design decisions.
- Page count 15 – 120 URLs against the sitemap, each on its assigned template within the per-row hours budget; multi-practice consolidation builds can run higher
- Templates 5 – 12 reusable templates registered from your Figma library — theme PHP, custom Gutenberg blocks, or Elementor Pro per your stack
- Custom logic ACF field groups, custom post types, taxonomies, menu structure, plugin integrations — scoped to your project
- Timeline 20 – 130 days end-to-end on a single-phase build at your typical review cadence; up to 200+ days with a reconciliation phase or longer client-feedback rounds. Calendar tracks your review rhythm — the hours budget holds either way.
- Effort 25 – 170 hours typical: development + QA iterations + project management, scoped against the workbook’s row-level Hours Estimated; complex multi-practice builds can run higher
- Team 3 – 6 specialists — lead developer, QA specialist, project lead, plus additional dev or content support on larger builds
- Hosting Default: your hosting (WP Engine, Kinsta, or your VPS). We can stand up staging on our infrastructure when the engagement calls for it — rare, usually for specific internal needs.
- Staging URL Provisioned on your hosting inside one week of project start; opened to your QA team after Site Checker fail-zero pass
- QA gates Site Checker fail-zero pre-handoff + parallel developer-track and reviewer-track backlogs worked down to zero before launch
Builds from the portfolio.
Partner engagements delivered for US marketing agencies. End clients named with permission; partner agencies not named.
What determines the hours budget.
Build budgets are set by the workbook, not by a global heuristic. Every sitemap row carries an Hours Estimated value; the aggregate of those rows is the contract. Below are the levers that move that aggregate, drawn from real engagements.
Single-location, single-phase builds in a well-documented template system. Straightforward form integrations, standard menu structure. Smaller QA tail.
Multi-location routing, per-location booking embeds, or a large treatment/service matrix. The QA reconciliation tail lengthens proportionally — each location multiplies the verification surface. Real example: 138h across 3 locations, 33 treatments, 47 URLs.
Two or more legacy domains folded into a single new-brand site. Redirect pairs sourced from each legacy domain add an internal-link reconciliation layer on top of the standard build scope. Blog-corpus imports (100+ posts) are the single largest budget driver in this shape — content import time, not bespoke layout.
When the agency's brand system is still in flight but the site can't wait. We run the build in two passes. First pass: build against the current design materials and close the dev phase. Second pass: update the visual layer to match the finalised brand system once it's ready. Hours for both passes are scoped upfront — the budget doesn't grow, but the calendar runs longer than a single-phase build because of the gap between phases.
Three to six specialists per engagement, depending on page count, custom-logic depth, and QA volume. QA share varies by shape: a multi-location fix-and-feedback tail may run 50–60% QA by hours; a single-phase with a clean template system runs closer to 20–30%. PM share is high on two-phase builds (stakeholder coordination across both phases); low on single-phase builds where the workbook does the coordination work.
Frequently asked, plainly answered.
Specific to this engagement shape — what we mean by it, what we own, what changes the hours.
-
Per row of your Sitemap. We populate the Hours Estimated column ourselves, row by row, before work starts — each page or template gets its own estimate, and the aggregate is the project quote. During the build we track per-page actuals against those row-level estimates and surface variance early, not at handoff. If a row goes over plan (a content-heavy migration, an unscoped forms integration), we flag it inside the build week with a re-estimate, before the variance accumulates.
-
That's a recognised Build shape, not a workaround. We treat Phase 1 (sitemap-driven first-pass build) and Phase 2 (templated-design reconciliation against the brand system) as named deliverables, each with its own QA gate. Treating Phase 1 as "build done" before reconciliation is the failure mode the playbook is built to prevent.
-
Both. The two-track structure is invariant — names vary per agency (SEO + AM, Issues + AM Issues, DEV + CX) — but launch only happens after both completion percentages reach the agreed threshold. Our internal Site Checker gate runs before either track opens, so your QA layer never starts against a half-baked staging.
-
Yes, materially. On a recent ~130-post blog migration we spent 89.5h on that single workbook row — exceeding the project's tracked dev hours overall (75h on Redmine, summed across the dev category). The blog row was a discrete sub-budget in the workbook, separate from page-count rounding; we surface it that way in the per-template breakdown rather than folding it into the headline page count.
-
It varies by shape. A two-phase multi-stakeholder build with brand-system reconciliation can run up to ~46% PM share of total hours on the most coordination-intensive engagements we've delivered. A single-phase content-import build runs 10–12%. Before quoting, we tell you which of these shapes your brief looks closer to. A single-phase build can honestly promise minimal coordination; a two-phase one can't — coordination is unavoidable, and we'd rather say that upfront.
Have a
brief ready?
Send us the Figma file, the sitemap workbook, or a one-paragraph description of scope. Within 24 hours: a sharp set of clarifying questions and a fixed-hours estimate against your per-row budget. NDA on request before we open anything.
Not sure if a Build is the right engagement? Compare to a Rebuild →