I Built a CMS at MSNBC Before Anyone Called Them CMSs

In 1996, I built a content management system before the term existed. The CMS industry is now worth $15 billion - WordPress alone powers 43% of websites. When I created Workbench at MSNBC, there was no category. We just needed non-technical journalists to publish without touching code.

The industry wouldn't have a name for this until years later. Looking back, Workbench was a CMS before we called them CMSs. It was workflow automation before the term existed. It was a low-code platform for content operations, built because the alternative was chaos. This was early in my 45 years in tech. The patterns it taught me have repeated ever since.

Updated January 2026: Added internal tool lifecycle pattern analysis and Monday Morning Checklist.

The Economics of Bespoke Tooling

In 1996, there was nothing to buy. Today, there is everything to buy. The build decision is now a cost decision.

Here is the math: a custom internal tool costs roughly $150K-300K to build (developer time, testing, documentation). A SaaS alternative costs $5K-50K per year. The breakeven is 3-6 years—but internal tools rarely get maintained past year 2.

Build vs. Buy TCO Calculator

This means most "build" decisions are economically wrong before they start. The internal tool will be abandoned before it pays for itself. The engineers who built it will move on. The replacement will cost another $150K-300K. You end up paying twice for worse results.

Workbench survived because it had executive sponsorship and ongoing maintenance budget. That is the exception, not the rule.

What Workbench Actually Did

MSNBC in 1996 was launching one of the first major news websites, simultaneously with the cable channel. News operations have specific needs:

Article lifecycle management. Stories move through stages: assigned, drafted, edited, reviewed, approved, published. Different people touch the content at each stage. Editors assign. Writers draft. Copy editors clean up. Photo editors attach images. Workbench tracked all of this.

The budget. In news, "the budget" is the list of stories you're working on. What's in progress, what's planned, what's being held. Workbench was the system of record for what stories existed and where they were in the pipeline.

Asset management. Articles need images. Images need captions, credits, alt text. Multiple images per story, multiple sizes per image. Workbench managed the relationships between content and assets.

Publishing automation. When a story was approved, it needed to go live. Workbench handled the build and release - generating the HTML, placing it in the right location, updating indexes, invalidating caches.

Non-technical users. Editors and writers aren't developers. They shouldn't need to be. Workbench gave them a web interface where they could do their jobs without touching code or servers.

The whole editorial workflow - from "we should cover this" to "it's live on the site" - was managed through one system. Users whose job was journalism, not technology.

The Problems It Solved

Here's what I saw before Workbench existed - publishing to the web was manual and technical:

Status tracking was informal. "What stories are we working on?" was answered by asking around, checking email, looking at shared folders. No single source of truth. Research consistently shows that teams without centralized tracking waste significant time on status communication—a pattern that persists regardless of industry or era.

Publishing was scary. Getting content onto the website meant FTP, file permissions, path structures. One wrong move and you'd break something. Only technical people could do it, creating bottlenecks. When things broke, debugging without Stack Overflow meant reading documentation and thinking hard.

Asset management was a mess. Images in various folders. No consistent naming. No tracking of what image went with what story. Finding the right photo meant hunting through directories.

Version control didn't exist. Stories got overwritten. Edits got lost. "What was the previous version?" was an unanswerable question.

Workbench made all of this manageable. Not through revolutionary technology—through clear workflow definition and good interface design. People doing the work could focus on the work, not the systems. This principle—tools should disappear into the workflow—remains the core of good internal tooling.

Why This Matters for Today

Workbench is relevant because the patterns keep recurring:

Workflow automation isn't new. "Low code," "no code," "workflow automation" - these are 2020s buzzwords for something we were doing in 1996. Non-technical people need to accomplish technical tasks. Build tools that abstract the complexity.

Content management systems evolved, not invented. WordPress, Drupal, Contentful, Sanity - these are descendants of tools like Workbench. As the history of CMS development shows, specific features change. The core problem - managing content through a lifecycle - doesn't.

Internal tools matter. Workbench wasn't a product. It was an internal tool built for one organization's specific workflow. But it was crucial to operations. The best internal tools are invisible - people use them without thinking.

Simple beats sophisticated. Workbench wasn't architecturally elegant. It was a VB application talking to SQL Server. But it worked reliably for people who needed to publish news quickly. Working and simple beats beautiful and unreliable.

The Build vs. Buy Question

Why did we build Workbench instead of buying something? In 1996, there wasn't much to buy. The CMS market barely existed. What did exist was expensive and designed for different workflows.

Today, you probably shouldn't build a CMS. Buy one. There are dozens of good options. The lesson isn't "build your own Workbench." It's "understand what problems you're solving, then find or build the simplest solution."

The right answer in 1996 was to build. Today it's usually to buy. Both answers come from the same principle: solve the actual problem with the least complexity.

What Non-Technical Users Need

Workbench taught me what non-technical users actually need from internal tools:

Clear mental models. Users understood articles, not databases. Stories have statuses, not state machines. The interface used their vocabulary.

Guardrails, not locks. People could make mistakes, but the system caught common ones. Missing required field? Warning before you proceed. Publishing without editor approval? Confirmation dialog. Prevention without condescension.

Fast feedback. When you clicked "publish," you knew within seconds if it worked. No waiting, no uncertainty. Long operations showed progress.

Recoverability. Mistakes happen. Workbench kept history. Stories could be unpublished. Versions could be restored. Nothing was destroyed by a wrong click.

Respect for their expertise. Editors know more about editing than developers. When we built Workbench, the tool supported their workflow—it didn't impose our workflow on them. Tools that ignore user expertise consistently fail to gain adoption.

The Pattern Across Decades

The terminology changes but the pattern repeats:

1996: Custom internal tools. You need workflow automation? Build it. Specific to your needs. Works for your team.

2000s: Enterprise CMS. Big vendors, big implementations, big consulting fees. Vignette, Documentum, expensive and complex.

2010s: SaaS CMS. WordPress.com, Squarespace, hosted solutions. Don't run your own servers.

2020s: Headless CMS, low-code, workflow automation. Contentful, Airtable, Notion, Zapier. As Smashing Magazine documents, the CMS landscape has fragmented into specialized tools you mix and match to build your workflow.

Different implementations. Same underlying needs: manage content lifecycle, enable non-technical users, automate the boring parts.

Why Internal Tools Get Neglected

Workbench was successful because it had executive attention and ongoing maintenance budget. Most internal tools don't get that treatment. An engineer who sees a problem builds them. A team depends on them. Then priorities shift toward customer-facing features and the tool gets neglected.

The pattern is predictable: an internal tool works well for its initial use case. Then requirements evolve. The original developer moves to a different team. Nobody wants to maintain someone else's code for an internal system. The tool becomes "legacy" within a year or two, limping along with known bugs.

Eventually the tool becomes so painful that someone proposes replacing it - usually with a new custom solution, restarting the cycle. Or the organization buys a commercial product, discovering that off-the-shelf doesn't quite match their workflow. Expensive customization or workflow changes that the team resists.

The lesson from Workbench isn't that custom internal tools are superior. It's that internal tools require the same product management discipline as external products. They need maintenance budgets. They need someone accountable. Without that organizational commitment, even well-designed tools become liabilities.

What I Would Build Today

If I were solving the Workbench problem in 2026, I would not build. I would compose.

The stack: Notion or Linear for workflow tracking. Contentful or Sanity for headless content. Zapier or n8n for automation. GitHub Actions for deployment. Total cost: under $500/month. Total custom code: nearly zero.

The economics have inverted since 1996. Developer time now costs $150-300/hour loaded. SaaS has commoditized everything Workbench did. The only reason to build custom internal tools today is when your workflow is so unique that nothing fits—and even then, think hard about whether your workflow should be that unique.

The real lesson from Workbench is not "build custom tools." It is "solve the real problem with the least complexity." In 1996, building was the least complexity. In 2026, buying and composing usually is.

"Understanding what problems you're really solving, independent of the technology du jour, is the skill that transfers across decades."