Southern Company Gas

Five brands. One parent company. Every update multiplied by five.

Author once, publish everywhere.

The Problem

Southern Company Gas operates a parent brand and four regional utilities. Each has its own site, its own content needs, its own stakeholders—but they're all saying versions of the same things. Safety information. Rate updates. Service announcements. Corporate communications. The same sermon preached to five congregations, each convinced theirs is unique.

The existing approach: each site maintained independently. Same content rewritten multiple times. Inconsistent messaging. No shared infrastructure. Every update multiplied by five.

Production involved multiple groups inside and outside the company. Publishing required external vendor assistance. Even simple copy edits underwent process—they couldn't "just change the copy" on their own.

So the content devolved to PDFs. A public utility posting PDF files in multiple languages on a website. Any time something had to go out, a PDF was posted. We constantly had to train them to think web page first, PDF only in cases that demanded it—like Chinese or Korean language versions. (There is no polite way to say "staggeringly bad" about a Fortune 500's web presence. There is also no inaccurate way.)

The question: How do you unify content production, design, and publishing across five properties without creating five times the work?

How I Got Here

My work partner had been brought on as a consultant and stepped into a project far too big for one person. He brought me in to handle strategy, content, and governance. I ended up learning Vue.js, writing code, pushing to Git, and deploying to Netlify. The work demanded it—there was too much to divide cleanly into design and dev. We both did everything that needed doing.

The full team was four external people: the two of us, a dedicated content person, and a contract designer—working with a host of internal stakeholders across the parent company and four regional utilities. Four people. Five brands. Three hundred pages. The math doesn't work until you build the system that makes it work.

The System

We built what Gartner calls a "composite content application"—the most accurate term for what this was. Maps, videos, written content, templates, components, all in code. More than a blog or a website. A publishing infrastructure that separates content from presentation and enables multi-site deployment from a single source.

We built publishing to five sites without being asked. It was just the smartest solution for the content distribution problems we faced.

Content Governance

We developed systems that solicited and approved content ideas, created a production process spanning writing, editing, and visualization, and allowed publishing to one or more websites. We taught our philosophy to internal employees and outside agencies responsible for asset production. Teaching people a philosophy is harder than building an application. The application does what you tell it. People have opinions about PDFs.

Content Model

The architecture has to accommodate both indifference and urgency.

Using Google's Zero Moment of Truth framework, we uncovered questions a user would ask, wrote answers, removed redundancies, and arranged content from very broad questions to very specific ones. Promotional pages answered broad questions. Leaf pages answered specific questions about a subject.

Diagram showing progression from unstructured information to querying hierarchy to content written to hierarchy to content deployed in pattern library
The content production system: unstructured information becomes queryable hierarchy, then structured content, then deployable patterns.

Design System

I translated brand guidelines into a component system in Figma for wireframes and content collection. Our authoring system was flexible, customizable, and reflected in full in Figma. We could cobble together wireframes in minutes, using them for content collection as well as communicating scope.

Figma component library showing customizable variations with adjustable variables for content, colors, and images
The Figma component library. Every component had configurable variables—swap content, adjust colors, change images—all matching what the code could render.

Publishing Infrastructure

I wrote code for components in HTML, CSS, and JavaScript inside the Vue.js framework. Gridsome built our static pages. I maintained an NPM package to share code across properties, modeled content types in Contentful, wrote GraphQL to extract content, integrated SendGrid and Twilio to capture data, and handled DevOps in Netlify.

Component library architecture showing how components are shared across multiple Southern Company Gas properties
Components shared across all five properties via NPM package. One codebase, five brands, infinite configurations.

What This Enables

The old model: five sites, five sets of content, five update cycles, five chances for inconsistency.

The new model: author once, publish everywhere. A single content source inherits brand-specific styling at the publishing layer. Update a safety guideline once; it propagates to all four regional sites and the parent.

Roughly 300 pages across five properties. Twelve templates following the ZMOT line of thinking—broad questions at the top, specific answers at the leaves—plus custom pages for leadership and board. Proper structural code. Alt text partnered with images. Contrast ratios that pass. Accessible usability throughout. Search optimization baked in.

All five sites launched. The composite content application has been live since 2022 and is still running. Nobody sees the system. The system works. That's the whole point.