Startups are prototypes

A startup isn’t just an early-stage company. It’s a mechanism to reduce uncertainty. Every early customer, product release and funding round exists to answer one question: have we learned enough to justify the next investment? A startup is essentially a super complex prototype designed to validate...

Strategy

2d ago

Shapeshifting the Future

Every year we open our doors for a week to a student trying to find their way into the industry. Not work experience in the shadowing-only sense but a real placement, with a real brief. We do the same for a roomful of UCL students, in the studio for an afternoon. From the outside, a career in this...

Studio

8d ago

Your biggest asset in an RFP, your website

Your biggest asset in an RFP, your website. I’ve spent most of my career in B2B, and at Made by ON I spend my weeks talking to leaders of the world’s most exciting B2B businesses. Lately those conversations keep circling one question, which I put to our strategists and UX team: what happens when...

Studio

21d ago

From static frames to a creative operating system

Looking beyond the flashy generative UI, shader effects and animation features at Figma Config signaled a deeper, more structural shift: the transition from a static repository of files and rules into a behavioural operating system. I left San Francisco with a camera roll of screenshots and pages...

Design

Engineering

1mo ago

Standardise the foundations, not the brand experience

Detailed work at scale comes down to one judgement: which parts of a project are worth building fresh for every brand, and which should be solved once and reused everywhere. Shared functionality on one side, brand expression on the other Engineering teams have plenty of frameworks and platforms to...

Engineering

2mo ago

Putting video back where it belongs

The problem with putting video in a git repo. The repo kept getting heavier, sprint after sprint. We were committing big MP4s next to the code, builds were slowing down, and deploys with them. Case studies lead with video, so every new client made it worse. We needed the media to live somewhere...

Engineering

2mo ago

The theme is the guardrail

WordPress can now describe itself to machines. WordPress 7.0 landed back in May with AI infrastructure in core. There’s an AI Client, a Connectors screen where the provider keys live, and the Abilities API, which actually arrived back in 6.9. Abilities are how core, plugins and themes describe what...

Engineering

15d ago

Cache Components: the right content at the right time

Cast your mind back to the earlier days of the world wide web. A website was essentially a digital document, the web a library, and the internet the mechanism of delivery. Updating a document meant editing HTML on your computer and uploading it to a server by hand, usually over FTP. In 1995 PHP...

Engineering

29d ago

We build by leaving things out

Most of what makes a WordPress site good is what we choose to leave out of it. WordPress runs a large part of the web on a big promise: whatever you need, there’s a plugin for it. That promise is one of its greatest appeals, and its most costly trap. Almost everything that harms a WordPress site...

Engineering

1mo ago

Letting type move

We treat type as something that sits still — fixed in place, headings always the biggest thing, motion bolted on at the end. For one Creative Spark we dropped those rules and asked what type could do once it started moving. Creative Spark is our in-house R&D session: ninety minutes, a single theme,...

Engineering

2mo ago

Twenty-four modules, one wrapper

Andy Purbrick Design

28 May 2026

3 min

Every case study was its own Astro page. That was the first problem.

Each page had its own layout logic, its own spacing decisions, its own way of handling full-bleed sections versus contained text. Some used inline styles. Some used one-off SCSS files. None of them agreed on what “default spacing” meant. Adding a new case study meant copying an old one, deleting most of it and hoping the parts you kept still worked together.

We needed a system where content authors write markdown and the layout stays consistent without anyone thinking about it.

The contract

The fix started with a single SCSS file: the contract. It defines every spacing and layout value the site is allowed to use, from page max-width and gutters to three tiers of vertical spacing and text measure widths. All fluid, all using CSS clamp() so they scale smoothly between mobile and desktop.

No component gets to invent its own spacing. Every module reads from these tokens. If a value isn’t in the contract, it doesn’t exist. One file changed, every page updates.

Side-by-side: the same case study page at mobile (375px) and desktop (1440px). Modules reflow and spacing stays proportional. The same modules at two viewport widths, layout adapts, spacing stays proportional.

Inside the wrapper

We built 24 components (Hero, TextColumns, Cards, ImageText, Slider, ClientQuote and 18 others) that all sit inside a single wrapper. The wrapper accepts a small set of layout attributes, each with a few named values that control width, spacing and proportion. CSS custom properties handle the rest.

The content author never writes layout code. They write container directives in MDX:

:::text-columns{layout="double" spacing="compact"}

Mosaic of rendered module types cropped from real case studies: Hero, TextColumns, Cards, ClientQuote, Slider, ImageText. A sample of the 24 modules. Each one only knows about its own content; the wrapper handles everything else.

The case study template maps each directive name (hero, text-columns, image-text, client-quote) to the matching component. The author picks which modules they want and in what order. The system enforces how those modules look.

What modules don’t need to know

Twenty-two case studies and five landing pages now run through the same template. Before, each page was a standalone Astro file with its own layout logic.

The surprise was how little the modules need to know about each other. A Hero doesn’t care what follows it. A TextColumns block doesn’t know if it’s inside a case study or a landing page. The contract handles the shared rules, ModuleSection handles the shared structure and each module only worries about its own content.

What actually ships

A content author opens an .mdx file, writes directives, saves it and the page is done. No custom template, no per-page SCSS. A new case study that used to take a developer half a day now takes about twenty minutes. Client work gets published faster, and nobody has to ask a developer to adjust spacing.

The testbed nobody will see

Andy Purbrick

Engineering

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.