We Needed To COPE

We had done it. It was early 2015 and our company which had prided itself on a culture of individual ownership and ingenuity had really stepped in it this time; we had empowered everyone.

Through multiple iterations of home rolled content management platforms we had finally arrived at a system where anyone across the whole organization could create a new page, use the graphic editor to arrange various molecular components, and once they were happy with their work they could publish their work live to the web. They could even create bespoke layouts per platform (desktop, tablet, mobile) — it was pretty handy! Development rejoiced. Merchandising high-fived. Everything was right with the world.

But as time went on, the cracks in the system began to show. Frustrated with the WYSiWYG editor’s customization options, content authors began to inject custom HTML and Javascript into the site. Pages started crashing as malformed markup spread around between authors. Content was stored as large blobs of markup in the DB, so when it came time to redesign there was no way to reformat the site content. We added a fourth platform (native) and realized that our handy platform-based view builder now insisted that all of old content be revisited so the authors could create a native view that could be consumed by the new platform. UX and marketing became frustrated that there was no way to enforce site standards. Authors were frustrated with the level of support the tool got. The business had prioritized speed at the expense of consistency and reliability and now we were at an impasse.

So we started talking. After a year of working in our fancy graphical editor, our users had come to realize that universally they wanted to refocus on what they were hired to do — not what the tool required them to do. For merchandisers, that meant not having to worry about layout or design as they created landing pages and added rich content to shopping pages. For marketing, they wanted to focus on creating compelling content and engaging offers instead of churning out landing pages and photoshop banner templates for everyone else. UX wanted to be able to focus on defining consistent experiences across the site and not playing the role of design cop. Heck, developers just wanted clear and concise feature requests that solved real problems for their coworkers. Everyone had needs that the tool was ignoring.

Beyond the user needs, there were serious technical concerns that needed to be addresses sooner rather than later. We had painted ourselves into a corner in a few very dangerous ways, but they all added up to a system that wasn’t scalable. Content was too coupled with presentation. Feature work was slowed down because of the complexity of the WYSiWYG editor. It was only a matter of time before our business growth would have put us in a place where we literally had no path forward when it came to content creation. Fortunately, it did not come to that.

The next honest conversation we needed to have was build vs. buy. Should we continue to build on the foundation we had built up in our custom CMS codebase or should we ditch it for a more plug-n-play-n-customize approach? We looked around — there were plenty of companies on either side of the aisle. If CNN and GE were running open source platforms, shouldn’t we? If NPR and BuzzFeed had built custom solutions, shouldn’t we? It seemed like a toss-up until we dug a bit more into the “why” of solutions like NPR. They had chosen to build their CMS because they felt like they could build business specific tooling that would support their business in unique ways that other systems couldn’t. Not only that, but they coined (and then publicized) this concept of Create Once, Publish Everywhere (COPE) which resonated deeply for us. We’re a company nestled in the heart of farmland in Northern California and as such, we have always had issues finding and retaining personnel. Our business had grown exponentially but our talent pool had not. Could a CMS that organized itself around the reduction of repetitive tasks and the future-proofing of content be a viable scaling strategy?

Definitely. And so we began…