Sometimes the best way to improve a process isn’t to make the existing process easier.

It’s to remove the parts that keep causing problems.

At ReelWorld Productions, our marketing website had become one of those problems. It wasn’t the company’s primary product, but it demanded a disproportionate amount of attention from both marketing and development.

The site was originally built with Drupal. Content updates were difficult for the marketing team to manage safely, and seemingly routine changes could introduce unexpected problems. Development regularly became involved simply to keep the site functioning.

But more concerning were the recurring security issues because the site was compromised repeatedly. We eventually moved away from Drupal and rebuilt around WordPress, hoping a different content management system would make the site easier to maintain.

It helped in some respects but the fundamental problems remained.

Eventually, after yet another round of issues, the president of the company asked me to find a better solution.

I started with a different question:

Did this website actually need a content management system at all?

Questioning the Architecture

CMS platforms solve a legitimate problem. They allow people who aren’t developers to create and modify content without changing application code.

But that flexibility comes with complexity.

Our marketing site didn’t need arbitrary layouts or an enormous ecosystem of extensions. Most of what we published followed predictable structures and branding rules.

Meanwhile, we were paying for capabilities we weren’t really using with additional maintenance, training requirements, dependencies, and attack surface.

Instead of replacing WordPress with yet another CMS, I proposed something much simpler:

Make the site static and automate the work required to publish it.

That shifted the responsibility of the system because rather than expecting marketing to understand the technical structure of a website, we could create a workflow around the kinds of content the company actually produced.

And rather than maintaining a dynamic server-side application just to deliver mostly static marketing content, we could generate the pages ahead of time and deploy the finished result.

The goal wasn’t to automate the old process. It was to design a process where most of the old problems no longer existed and that distinction became central to the project.

Building the Publishing Pipeline

I introduced a Gulp.js-based build and deployment workflow to automate the repetitive work involved in maintaining and publishing the site. This meant the build process could take source assets, process them consistently, generate what the website needed, and prepare the finished output for deployment.

Tasks that previously depended on someone remembering a sequence of manual steps became repeatable operations that improved consistency, but it also changed how we thought about the site.

Shared layouts, styles, components, and branding rules could live in one place. Improvements made to that foundation could flow through the site without requiring someone to reproduce the same changes manually across dozens of pages which became especially important as the company’s product portfolio grew.

One System, More Than 100 Branded Pages

ReelWorld didn’t simply need a corporate marketing site. Instead we needed to support a large collection of product-specific experiences, each with its own branding and content while still belonging to the same overall family.

Building those independently would have created exactly the maintenance problem I was trying to eliminate.

So I helped establish a process that separated what was shared from what was unique and the underlying structure and publishing workflow could remain consistent while individual pages supplied their own branding, assets, and content.

That system ultimately supported the creation and deployment of more than 100 uniquely branded pages we I treated every new page as another small web project, we could treat it as another instance of an established publishing system.

That made the process substantially faster and, just as importantly, more predictable.

Creating a Workflow Between Departments

A major reason the previous sites had struggled was that maintaining them crossed organizational boundaries. This was because marketing understood what needed to be communicated, design understood how the brands should look. development understood how the website worked but the publishing process needed all three without requiring everyone to become an expert in everyone else’s job.

Part of my role became defining how those responsibilities fit together.

Rather than handing marketing a general-purpose CMS and expecting them to understand the implementation, we could establish a workflow where content and branding entered the process in predictable ways. Development could maintain the underlying system, design decisions could be represented consistently in reusable structures and marketing could concentrate on the material being published. We needed a process that could connect those responsibilities.

That was an important leadership lesson for me: sometimes the architecture of a system isn’t just about how software components communicate. It’s also about how people communicate through the software.

More Than a Marketing Site

The overhaul also gave us an opportunity to rethink what the company’s online presence could do.

I led significant portions of the frontend architecture and worked on richer, data-driven experiences rather than limiting the project to static promotional pages.

One of the most substantial features was an interactive media player capable of presenting and streaming hundreds of tracks that presented a very different challenge from generating marketing pages. The interface had to make a large catalog approachable while delivering the kind of responsive experience users expected from an interactive product.

It was an example of something that became important throughout my career: choosing architecture based on the problem instead of forcing every part of a system into the same model.

The marketing content benefited enormously from being static and the media experience needed to be dynamic. There was no reason those two ideas couldn’t coexist.

Automation as Architecture

It’s easy to think about tools like Gulp.js as build utilities but for this project, automation became something larger.

It was part of the architecture.

The build process encoded decisions that previously existed as instructions, habits, or tribal knowledge. Instead of telling someone how an asset needed to be processed or how a page needed to be assembled, we could make the system perform those operations consistently.

That reduced opportunities for human error and made deployment considerably more repeatable which meant improvements to the process benefited everyone using it.

A developer didn’t have to remember how another developer had deployed something six months earlier. A new product page didn’t require rediscovering the workflow. The system itself increasingly became the documentation for how the site was supposed to be built.

Good automation doesn’t merely make a task faster. It turns knowledge into infrastructure.

Faster Wasn’t the Only Goal

The new architecture improved performance and accelerated deployment, but those weren’t the only measures of success because we had started with several distinct problems: the site was difficult to maintain, content changes caused problems, development was repeatedly pulled into avoidable maintenance, security incidents were consuming attention, supporting many separately branded experiences was cumbersome and publishing involved too much manual coordination. The new system addressed those problems together because we stopped treating them as unrelated symptoms.

A static architecture dramatically simplified the runtime environment. Automation made publishing repeatable. Shared structures reduced duplication. A defined workflow gave different departments clearer responsibilities. And the branded-page system gave the company a way to scale its online product presence without scaling the maintenance burden at the same rate.

What This Changed for Me

This project expanded my idea of what frontend leadership meant. It wasn’t simply making architectural decisions about JavaScript or writing the most important components. It meant looking beyond the code and asking why the team was repeatedly experiencing the same problems. It meant coordinating technical decisions with the needs of marketing, design, leadership, and the people responsible for maintaining the result. It meant recognizing when a familiar solution—a CMS—wasn’t necessarily the right solution simply because the project was a website. And it meant building tooling that allowed other people to work effectively without needing to understand everything happening underneath it.

I’ve used many different frameworks and build systems since then. Gulp.js itself is no longer particularly important to how I work but the lesson behind it absolutely is:

When a process is painful, don’t immediately automate the steps in front of you. First ask whether all of those steps should exist.

That principle has followed me into much larger application architectures, deployment pipelines, reusable component systems, APIs, and the development workflows I build today.