W'A.I Studios

SYS.01 The challenge

The old w-ai.co.uk read as an AI marketing supplier: a services catalogue, page after page of what could be offered. The company it needed to describe is different: an applied-intelligence company with three divisions, Grow, Build and Know, each strong enough to carry its own section and each backed by real work.

That repositioning set a hard constraint. If the site claims a capability, the claim has to land on something that exists. Every statement needed a route to proof, and the proof had to be labelled honestly: no borrowed credit, no implied wins.

SYS.02 The method

The site was built through the W'A.I Site Toolkit rather than around it, the toolkit's second real project and its shakedown run. The toolkit is a clone-and-configure engine plus a post-skin: one project config file carries the brand tokens, URL structure, taxonomy, page map, SEO and logo-wall data; a token-triggered assemble endpoint wires and skins the site; the result is verified whole-site in a browser rather than sampled.

• Staging first. Everything happens on a cloned WordPress staging site and is signed off there. Nothing is shaken down on production.
• Audit before touching anything. A full sweep of the existing site ran first: 15 pages captured in full, ~115 unique assets indexed and preserved, including the partner logo wall.
• Config, not clicking. The engine wires and skins; it does not invent layouts. Design lives as code in design/, so it can be diffed and re-run.
• Credentials stay with the client. The deploy steps are documented as a runbook the site owner runs; hosting credentials are never handled on their behalf.

SYS.03 Creative response

• A living engine, not a hero image. The homepage core is a canvas system that reports real state: telemetry, radar sweep, orbit nodes with target-lock, an attention ring that tracks the cursor, and a single breathing beacon in place of a wordmark. It has three states: idle, active, speaking. It pauses off-screen and renders a static frame under reduced-motion.
• Three-division architecture. Grow, Build and Know as standalone sections, each with capability clusters and a route to proof rather than decorative case cards.
• The deployed-work wall. The partner logo wall stays, and every logo opens an individual case-study post, the proof mechanism for the whole site.
• A case-study library with provenance. Assembled from 20+ years of design, comms and technology work, filed into two clearly separated buckets: W'A.I Clients (genuine W'A.I Studios engagements) and Prior Experience (work delivered elsewhere).
• SEO and AEO strategy. Keyword and question maps per division, plus a ranked playbook for being visible to AI assistants: not only to search engines.

The honest log

Four full design iterations before the front page was right. Two of the bugs along the way are worth publishing, because both were cheap mistakes that cost real time, and because how they were eventually found is the actual method.

A stray }} in the stylesheet closed the rule block early. Every rule after it was discarded by the parser without error. The visible symptom was a giant white box on the homepage, the collapsed chat panel's .frame border, rendering unstyled. Nothing in the markup was wrong. CSS fails quietly, and a quiet failure downstream of the actual typo looks like a layout problem.

Fixed · hero now sits on pure dark ground

.grid was doing two jobs: the hero layout container and the logo-wall tile grid. The tile styling painted a panel behind the hero that should not have been there. It survived four versions and several confident, wrong diagnoses, because each fix was aimed at the hero, and the rule causing it belonged to a component several hundred lines away.

Fixed · scoped naming, no shared generic class

The fix did not come from reading the CSS again. It came from injecting a script into the running page that outlined and named any large element painting a background. It found the culprit in about a second, the thing repeated inference had missed across four attempts. Reasoning about what the code should render is a reconstruction; asking the live page what it is rendering is a measurement.

Adopted · self-diagnosis before re-inspection

Verify against the real thing, whole-site, every time. Reconstructions lie: a mental model of the page, a rendered preview, a sampled check of two templates. All three of these bugs were invisible to inference and obvious to measurement. The verification step is not a formality at the end of a build; it is the part of the build that finds what everything else missed.

What it proves

• The method is repeatable. This was the toolkit's second project, not a bespoke one-off. The same config file, the same assemble step, the same verification loop.
• Design-as-code is reproducible. The look lives in version-controlled files, so it can be diffed, reverted and re-run, including the four iterations it took to get here.
• Reporting beats performing. A site that displays its own real system state, live status, honest provenance labels, an in-progress marker on this very page, is more persuasive than one that performs confidence it hasn't earned.

SYS.04 The honest log