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

16h 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

8d 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

22d ago

Twenty-four modules, one wrapper

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"...

Design

1mo ago

The form we actually trust

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...

Engineering

1mo ago

We test the revenue path

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...

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

17d ago

The cache that doubled as a coordinator

The rendering engine is what visitors see. The data layer feeds it, and keeping it stable under load was the less glamorous half of the build. This is the second post in the ON Labs series. The first covered the WebGL engine: shaders, draw calls, the GPU-level stuff. This one is about what happens...

Engineering

29d ago

The testbed nobody will see

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...

Engineering

1mo ago

Two months in Three.js, we started over

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...

Engineering

1mo ago

The cache that doubled as a coordinator

Mike Leonard Engineering

4 June 2026

2 min

The rendering engine is what visitors see. The data layer feeds it, and keeping it stable under load was the less glamorous half of the build.

This is the second post in the ON Labs series. The first covered the WebGL engine: shaders, draw calls, the GPU-level stuff. This one is about what happens before a single pixel renders: fetching project data from an external API, caching it and making sure concurrent requests don’t trip over each other.

The original problem

Labs pulls project boards and media assets from Air.inc. Early on, every page request made a fresh API call. It worked fine in development and immediately hit rate limits in production. Multiple serverless instances spinning up at once meant dozens of identical requests hitting the same endpoints within seconds.

You can’t just “add a cache” when you don’t control how many instances are running or when they start.

One request rebuilds, the rest wait

The core idea is coordination: when the cache expires, only one instance rebuilds while the others wait. If the rebuild takes too long or fails entirely, stale data gets served instead of an error. A crashed process can’t hold the lock forever; it expires on its own.

One request rebuilds. The rest wait or serve stale. No stampede.

It’s stale-while-revalidate implemented in application code, because the hosting layer doesn’t offer it natively for API-driven data. The storage layer doubles as both cache and coordination mechanism between instances that have no other way to communicate.

Cache versioning and the video pipeline

The cached payload carries a version number. When the data shape changes (new fields, restructured assets) the version bumps and every instance treats the old cache as expired. No manual purging, no deploy-time clears.

A separate store handles optimised video URLs. Each asset’s source maps to transcoded variants at different quality levels, cached per-asset with their own expiry. A concurrency limit keeps the transcoding lookups from overwhelming the provider.

Labs loads quickly. Transitions run smoothly. Filters respond without delay. Nobody sees lock negotiation or stale fallbacks or version checks. They see a portfolio that works.

What the data layer protects: a fast, reliable first impression.

Why build this yourself

Most caching is straightforward: set a TTL, serve from cache, refresh when it expires. The complication is concurrency across serverless instances with no shared memory. Off-the-shelf HTTP caching doesn’t solve that. Coordination in a stateless environment means leaning on a shared store and building the locking yourself.

Not glamorous work. But without it, two people visiting at the same time could bring the whole thing down. That’s not hypothetical.

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.