New sites, built from your brief.
Not from a template we guessed at.
A Website Build means a blank canvas, a workbook with your URLs and hour estimates, and a team that executes against the spec 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, and a row-level hours estimate for each page. We build against that 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 booking-matrix logic gets wired, internal links get reconciled, 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 — multi-location routing, booking-matrix wiring, ACF field groups, menu structure — 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 credentials handed over, 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 Multi-location routing, booking-matrix wiring, ACF field groups, menu structure — implemented in the first stretch, reconciled in the second
- Timeline 20 – 130 days end-to-end on a single-phase build; up to 200+ days when the engagement runs as build + reconciliation phase
- 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 WP Engine, Kinsta, or your VPS — we deploy to your environment, not ours
- Staging URL Inside one week of project start; admin credentials handed over 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.
White-label 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.
Separate Redmine sub-tree for the templated-design reconciliation phase. First-pass build closes, then a second stretch reconciles the agency's evolving brand system against the live staging environment. Calendar stretches without breaking the hours budget.
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%. We tell you which shape your brief looks like before we quote, because the same "discipline, not overhead" line doesn't fit both.
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 →
Send us a brief