Two months in Three.js, we started over

28 May 2026

2 min

Two months into a Three.js prototype, the transition we wanted still wasn’t there. We could see it in our heads and not on the screen.

That was the moment we started over from scratch.

Labs uses real-time shaders, physics-style interactions and transitions that happen at the GPU level. That behavior took roughly 6,000 lines of hand-written WebGL 2 and four months of iteration. We needed direct control over every draw call and every animation frame. Existing libraries would have saved time upfront and cost us flexibility every week after.

Straight to the GPU

There’s no Three.js, no Pixi, no framework sitting between our code and the GPU. A single setup module compiles vertex and fragment shaders, builds a shared quad and manages four shader programmes. Every draw call goes through it.

Shaders manipulating geometry in real time

Feeding it real data

From there, modules handle different responsibilities: the canvas and render loop, the orbs with its GLSL transforms (bulge, twist, rotate, scale) layered through custom blend modes, full-screen post-processing for bloom and grain, a raycaster for hover detection, texture management, input handling, performance monitoring. Shared helpers cover noise functions, color math and UV manipulation.

The data layer pulls project boards and assets from the Air API, then caches them through Netlify Blobs with a distributed lock mechanism. The lock prevents stampedes when the cache expires: only one request refreshes the data while others serve the stale version.

We rebuilt that integration in October 2025 after the original approach (fetching on every request) started hitting rate limits. The lock-and-cache layer landed in February 2026 alongside SpeedyClip for asset delivery.

The UI around the canvas

A set of Astro components handles everything outside the WebGL viewport: search, filters, tabs, scroll controls, hover labels. They talk to the canvas through a bridge layer that translates DOM events into render-loop updates. The result is that filtering a project list triggers a shader transition, not a page reload.

Timeline

October 2025: Air API integration rewrite.

January 2026: Soft launch of Labs.

February 2026: Netlify Blobs caching with distributed locks and SpeedyClip rollout.

The UI and the canvas talk through a bridge layer for filtering.

What 6,000 lines bought us

Labs is often the first thing a potential client sees when they explore our work. The way it moves and responds tells them something about how we think before they’ve read a word.

Writing your own renderer is a terrible idea for most projects. The visual behavior we wanted doesn’t fit anyone else’s scene graph. The cost is 6,000 lines we maintain forever — and the page makes that worth it.

We test the revenue path

Andy Purbrick

Field Notes

28 May 2026

2 min

The contact form is the only page on this site that generates leads. So that’s where the tests live.

We don’t chase coverage numbers. What we have is a targeted set of tests aimed at the things that would hurt if they broke: the forms, the pipeline that processes submissions and the CI that catches problems before production.

Dependency injection as a testing technique

Our submission pipeline accepts a dependencies object containing every external service: CRM client, file uploader, error notifier, spam verifier. Both form handlers use it.

That turns the pipeline into a pure function. In production, real services get passed in. In tests, we inject fakes directly — no mocking library, no patching globals. The function doesn’t know whether its dependencies are real.

What the unit tests cover

Five scenarios, each chosen because we saw it go wrong or imagined it going wrong in a way that costs money:

Date formatting for availability labels. Garbled dates look unprofessional in client-facing notifications.
File upload fails after lead creation. Losing a PDF is recoverable, losing the lead is not.
Derived fields reach the CRM correctly. Silent data mismatches are the worst kind of bug.
Fatal failures alert the team and rethrow. A swallowed error means a lost inquiry.
Newsletter signup blocks low-scoring spam while still capturing legitimate subscribers.

What the e2e tests cover

The e2e suite tests what the user actually sees: inline validation messages appearing as they type, the success screen after a valid submission, the error state when something goes wrong. Three form variants (start-a-project, minimal and newsletter) are each tested through the real UI in a headless browser. Playwright intercepts server calls at the network layer, so the tests run without a backend but the user-facing behavior is identical to production.

Why Node’s built-in runner

We use Node’s built-in test runner — not Jest, not Vitest. The DI pattern means tests are just function calls with fake inputs, so there’s nothing to mock and no lifecycle hooks to manage. A test framework would add a dependency and a configuration layer for problems we don’t have. The built-in runner handles assertions and test grouping, which is the whole requirement here.

The same philosophy extends to e2e. Playwright intercepts network calls so the tests run against the real UI without touching real services — the suite runs anywhere node does, with nothing to spin up first.

What it caught

Since this setup went live, no form submission has been lost without the team knowing about it within minutes. Each test is still just a function call with fake inputs and a check on the output.