9 projects · 0 live & verified · a project is COMPLETED only when VERIFY passes (site confirmed live) · stages that don't apply to a project are simply absent from its bar

How the pipeline works

Every site moves through the same stages, left to right on each bar. A project is COMPLETED at VERIFY — the site confirmed live with rankings protected.

1. DIAGNOSEoptional
   A full SEO audit of the existing site before anything else is touched: what ranks, where the traffic actually comes from, what is technically broken, and what is earning links. For a site with real rankings this decides what the redesign must never break. Optional for brand-new sites and prospects — it's whatever audit opened the door.
2. BASELINE
   The insurance policy. Every URL, title, meta, heading, ranking position and Core Web Vitals reading is recorded before anything changes, so the VERIFY stage can later prove nothing was lost at launch. Skipped only on speculative prospect showcases — and becomes mandatory the day they convert and a real cutover is planned.
3. CONCEPT HOME
   The homepage is designed and built as real working HTML first, at full fidelity, and it doubles as the sales asset used to win the work. It's reviewed view-only before any effort goes into the rest of the site, so a wrong direction costs one page, not twenty. Approving it approves the DIRECTION, not the final markup — the homepage is then redone properly through the wireframe gate like every other page.
4. CONCEPT APPROVAL
   The first of the two sign-off gates. What is approved here is the DIRECTION, on the concept homepage — not the final markup, since that page is rebuilt through the wireframe gate afterwards. It goes out as a plain staging link with no review campaign attached, because one page is a partial build. Who approves it is recorded by name: on some clients it is Jack's own direction check, on others the client or prospect, since this page doubles as the sales asset that wins the work.
5. MESSAGE MAP
   Once the direction is bought, the argument is settled for every page still to be built: awareness state, target keywords, the order the sections have to run in, what job each one does and where the proof goes. This is what the wireframe options are drawn against and what says which inner-page imagery is needed. It sits after concept approval on purpose — a speculative one-pager for a prospect stops at that gate and never builds an inner page, so it never pays for this step. The wording itself waits, deliberately: see COPYDECK.
6. WIREFRAMES
   Before any page of an archetype is built, that archetype (homepage, service page, case study, blog post…) gets five cheap black-and-white layout options. One is picked, and the pick is recorded and binding. Five cheap options beat one expensive guess: iterating full-fidelity concepts one at a time measured four rounds of rework where one wireframe round would have done.
7. COPYDECK
   Now the words. With the layout picked, the copy is written into its actual slots and edited in place until it's signed off, one shot per archetype. This runs after the wireframe rather than before it because copy written against slots nobody has chosen yet has to be rewritten once they exist — which meant paying for it twice.
8. DESIGN PAGES
   Every inner page designed and built to the approved direction, deployed as a full working showcase on staging. Wireframe picks are approved per page archetype before build-out, and the whole site is authored to the Client-First naming standard from the first line.
9. FIGMAoptional
   Optional loop, sitting between the two approval gates: the build is captured into a componentised Figma file when the project wants design-tool editing or a formal design asset. When it runs, the Figma file becomes the surface DESIGN APPROVAL happens on — it does not add a third approval. Skipped when the HTML build itself is the reference.
10. DESIGN APPROVAL
    The second and last sign-off gate, and the one nothing downstream starts without. There are only ever two: whichever artifact IS this project's design reference gets approved here — the Figma file when the Figma loop ran, otherwise the Cloudflare build, or the CMS staging build when the project reviews there instead (in which case this gate lands after Build, and that is not out of order). On a web surface the client walks the complete site in their own browser, no logins, pinning comments straight onto the pages. Rounds continue until every page is approved.
11. BUILD
    The approved design is rebuilt on the client's own CMS — Beaver Builder, Elementor or Webflow — page by page, and screenshot-compared against the approved reference until it matches on desktop, tablet and mobile.
12. NATIVISE
    Anything built as raw HTML inside the CMS is converted into native, client-editable modules — so the client can safely edit their own site later without a developer.
13. PRE-FLIGHT
    The launch checklist, before anything is flipped: every old URL's redirect mapped, forms tested end-to-end, tracking firing, 404s handled, performance passing, and the live site's plugin/theme versions matching what was built against.
14. CUTOVER
    Launch. Fresh off-server backup first, then the push manifest is walked step by step and the new site goes live on the real domain — site chrome last.
15. VERIFYcompleted = live
    The gate that makes a project COMPLETED. The live site is re-crawled and diffed against the BASELINE snapshot: every old URL must 301 to its new home, rankings are re-checked, pages are pixel-compared. A pass means the site is confirmed live with nothing lost.
16. STABILISEpost-live
    The 2–4 week watch after launch: Search Console coverage and 404s monitored, rankings tracked against the baseline, client fix rounds handled. After this the website is complete — everything beyond is ongoing maintenance and growth.