The testbed nobody will see

28 May 2026

3 min

Every case study was a standalone Astro page with its own layout, its own component imports and its own way of breaking on mobile.

Twenty-two of them. Each one built at a different time by a different combination of people, with whatever patterns felt right that week. Changing shared behavior (a hero transition, a spacing value, a navigation pattern) meant touching every file individually. The September 2025 release that started consolidating them changed around 200 files: roughly 13,000 insertions and 39,000 deletions, most of it duplicated layout code that no longer needed to exist.

We needed every case study to run through a single template and a shared set of modules. The migration took five months.

What lives in the testbed

We built a case study called testbed. It’s marked private: true and never appears on the public site. Its only purpose was to stress-test the template system before we touched real client work.

We loaded it with every module combination we could think of: heroes with video, text columns in every layout variant, cards with tight spacing, sliders, quotes, image-text blocks at different measures. If the template could handle the testbed, it could handle anything real.

The Testbed case study page: stacked black-and-white technical test patterns and circular targets used as module pressure tests, never visible publicly. The testbed: every module combination we could imagine, validated before touching real client work.

The testbed absorbed the risk that would otherwise land on a real client page. Rendering bugs surfaced in private, not in production.

The timeline

September 2025: The first release introduced unified blocks: accordion, floating nav, slider. Around 200 files changed in a single PR.

November 2025: CaseStudyTemplate.astro went live. We migrated Air first as a proof of concept, then activated Token, Hayah, Atelier100, London Design Festival, London Design Biennale and Bhutan in a batch.

Late November 2025: The testbed launched. Every edge case we could imagine, validated against the real template.

January 2026: The remaining 16 case studies were rebuilt using the module system. Migration complete. Twenty of the 22 now run through the unified template. None fall back to the legacy rendering path.

A case study today

An .mdx file with frontmatter and container directives. Media is referenced by short asset IDs that the rendering layer resolves to optimized images or video. The Air case study has 30 directive blocks (hero, text columns, cards, sliders, quotes) and the entire page is just markdown and asset references.

Split view: the air.mdx source file open in VS Code on the left, the rendered Air.inc case study page on the right. Directives and asset IDs on the left. The rendered page on the right.

The template reads the MDX, maps each directive to its module component and outputs the page. Next-project navigation is randomized — a small UX detail that means a repeat visitor never hits the same suggestion twice.

The work that paid for itself

The testbed. Building something nobody will ever see felt like wasted effort at the time. Five months later, it had earned its place: every bug it caught in private was a bug that didn’t ship to a client’s page. We still add module combinations to it whenever we build something new.

The form we actually trust

Rhona Mackay

Field Notes

28 May 2026

3 min

In February 2026, we replaced our contact form with a submission pipeline we built and own.

For the two years before that, it was a Pipedrive iframe inside our page. We had no control over fields, no client-side validation, no error handling beyond whatever Pipedrive showed inside its frame. When a submission failed, we found out from the client, not the system.

A screenshot of the new form we designed, built and tested. A form we built, designed and control.

Two forms, one pipeline

The start-a-project form is the full version: budget, brief, file upload, preferred dates, auto-detected timezone. It’s built as a Preact component with React Hook Form and Zod handling validation on the client. A minimal variant, just name, email and consent, runs on the AI Brand Engine page where a lighter touch makes more sense.

Both variants share the same submission pipeline. Different form surfaces, identical processing underneath. Every entry point gets the same validation, error handling and recovery, regardless of which page the inquiry came from.

The pipeline

The submission pipeline handles the sequence after the form is sent: validate with Google Recaptcha, create the contact and lead in our CRM, attach any uploaded files and send a confirmation email. Newsletter signups follow a shorter version of the same flow.

Both pipeline functions accept a typed dependencies object and every external service is injected rather than imported directly, which keeps the pipeline decoupled from its environment and makes each service boundary explicit. (How this enables testing is covered in a separate post.)

When things go wrong

If the lead is created but a secondary step like file upload fails, the submission still returns success to the user. The lead is safe. A structured alert fires to our team channel with enough context to recover manually.

Fatal errors, when the lead itself fails to create, alert the team with the same detail and rethrow so the user sees an error state. Nobody loses an inquiry silently.

Zod on both ends

The server-side actions run the same Zod schema again on the incoming data. Same validation, different boundary. A tampered request that bypasses client-side checks gets caught before it reaches the CRM.

From the user’s side

A form that validates as they type, shows clear error states when something’s wrong and lands on a confirmation screen with links to Labs and our Instagram, not a generic “thank you” page. They don’t know about the pipeline. They just know the form worked and the response didn’t feel like an afterthought.

The contact form's success state: "Thank you! We've received your submission and will reach out within 24 hours," followed by links to our Instagram and Labs, sitting below the form's privacy checkbox and Submit button. The success screen — links to Labs and our Instagram, not a generic thank-you message.

Since the pipeline went live in February, every submission failure has alerted the team within seconds, with enough context to recover manually.