Creating a CMS Through Slack

We recently launched Stanza Plus, our subscription service that gives users access to our library of unique calendar content. Our content team needed a tool to add content to the website without going through the dev team. Knowing that complexity is the enemy at most startups, our Engineering team had to think outside the box to help us solve one of our recent roadblocks: creating a CMS from scratch.

As a small start up, it’s critical that we use all of our resources to achieve maximum net productivity. And that’s not just something we say…we can’t afford to do it any other way! With the addition of Stanza Plus to Stanza’s product suite as our first paid B2C product, rapid design and content iterations are key to adapting Stanza Plus for our target user.

Stakes are high

The idea was to build a very simplistic Content Management System (CMS) for our marketing team to apply updates to our page completely independent from the development team. This is crucial as there are hundreds of updates required each week.

Copy, images, and logos are all implemented via boton commands in Slack.

We settled on building out a Slack CMS for the following reasons:

1. The team is already familiar with the Slack UI/UX and we already use Slack commands for various internal tools, such as deploys, github branch merging, common database lookups (e.g. lookup a document shortname based on display name), etc
2. Using a public channel makes correcting problems much easier
3. Building out a CMS UI between limited developers would too long
4. Ability to test on staging + limit functionality before causing fatal production errors (since this will be made for non-technical employee will be directly hitting the database)

Formatting

We used a very simple approach and created a new collection in Mongo to store all updated changes. We used the following format when calling these commands:

“Boton action plus collection environment name attribute value”

• Boton — calls hubot (Slack’s open source chat robot) to start listening
• Action — replaced with add, remove, or updated
• Plus — added to differentiate other commands which update our regular categories
• Collection — differentiate between updating Calendars or Categories
• Environment — Either ‘dev’, ‘staging’, or ‘production’ so employees can test before directly editing our production database
• Name — calendar or category name which you would like to edit
• Attribute — which attribute of the calendar/category you would like to edit
• Value — what you would like the new value to be

Proactive Work Saves The Day

A lot of proactive work was needed to safely and successfully touch our database globally within the company:

1. Data Validation: We made sure to put in checks to ensure each input could be handled by our endpoints. An example is the command to update category images: with the potential for a user to pass in a bogus image and break the frontend, we needed to download the image, ensure the image existed and the URL was public before using that specific URL.
2. Rollback: We hooked up document histories with both of these collections to save old versions of these documents, which we can easily rollback to in the case of invalid input that does not get caught by the initial data validation layer.

Unforeseen Challenges

1. Formatting was error prone: After finishing all commands and inputting them into a spreadsheet for our company to use, we realized copy/paste would not work properly for a lot of cases. Odd spacing, different types of quotation marks, and a few other quirks needed to be fixed on the fly.
2. Resistance to using staging: Since we had an environment variable in our commands, we required the user to run the commands twice, once on staging and once on production. This was met with opposition since the work took twice as long as running them once. Ultimately it’s the safer choice of course!

We’ve saved ourselves countless hours by creating a CMS through Slack. This project took less than a month end-to-end.