Going headless

I joined GitHub in early 2022. At the time, I was obviously clueless about the internal ongoing upcoming moves like Copilot and the focus on enterprise. I admired the homepage and the design team's work; it was the pinnacle of Web 2.0 design. I loved the WebGL globe and the buttery smooth Git line scroll animations weaving the story of the software development lifecycle through the GitHub feature ecosystem.

The shift toward enterprise software is done. GitHub is "big" tech. Open source is in everyone's heart but clearly not the money maker. This shift has led to a move away from the custom-built pages I once loved. Many of the creators of those have since moved on, likely because they anticipated what I’m about to describe.

The era of Mona's quirky stories unfurling over 10,000-pixel-long pages is gone. GitHub's website isn’t designed for developers anymore, but for decision-makers, CTOs, and technical managers, those with access to the enterprise wallets.

GitHub, like many tech companies with a growing website, is adopting a headless CMS. It makes too much sense on paper. We have a web design system, SEO and corporate marketing ambitions, limited design resources, a big budget, and an enthusiastic (and large) marketing team. What can go wrong?

It’s been 2 years and we’re starting to publish decent-looking pages. We’ve reinvented CSS, but worse, with thousands of content types, content models, and templates... This transition made me consider the true cost of custom builds. Although more resource-intensive, they offer a distinct value that few systems can replicate. That value is something designers, developers, and those who care about "quality" (in its holistic sense) notice. This is also often referred to as taste. A flexible, tastefully designed set of templates is the goal here.

I remember working on web apps where we used the WordPress API to basically do the same as what modern headless CMS does these days. It’s nothing new to offer a flexible backend and an API without a preset frontend. However, today's tech is a lot heavier, making the headless deal a lot harder to swallow.

I blame React. This headless approach promised to click with our design system seamlessly. Surely, the previous Rails stack was not designed for scale but for originality and quality. GitHub is a software company, everything started in the product monolith – Not ideal for marketing.

Like most large tech companies, GitHub design systems follow the atomic framework. The major limitation of Headless CMS is to only support Organisms (templates), not molecules or primitives. That means only a few variants of organisms (in the form of section templates) can be implemented before the backend UI becomes a hairy mess. The lack of granular control offered by layout and color primitives is the biggest loss. Balancing usability (constraints) and design quality (outcomes) is the crux of this transition.

GitHub is not an indie website, it can afford this. I question the relevance of the effort not its merit. After all, a website is a website.

What trips me up about headless CMS is the promise of needing no technical resources (design and engineering) by empowering anyone to publish pages. Even if the perfect setup accomplishes this, the time is gone. Headless is optimizing for 2016 standards, playing the good old SEO landing page game. Hearing marketing executives, we're always one landing page away from figuring out conversion.

Have you heard of AI? Does it care about our landing pages, templates or not? The people who do care—namely my fellow webmasters—are likely to be disappointed.

← Index / Published on 2025-03-13