Taking Our Own Advice

Here at Sendwithus, we like to practice what we preach, and one thing we spend a lot of time talking about is how to remove developers from what are essentially marketing workflows. In fact, most of what we’ve built has been specifically to address that.

Complex web applications are dangerous places for content creators and marketers. The stress of setting up a development environment can take years off your life and an entire day or two of work just to be able to deploy a copy change is a big, unnecessary time sink.

Nobody should ever have to experience the pain and agony of breaking production just to update the text on a landing page. At Sendwithus, we take care of our content creators and we spent some engineering efforts to rectify this situation. It was decided that this process is completely unnecessary to do something so simple.

Artist's rendering of Alex deploying to production

Actual footage of marketing deploying to production

A few months ago we started a project to move our landing pages out to their own Github repository so they would have their own procedures for deploying, ease-of-use for copy writers, etc. We now have a functioning static landing page setup deployable to Amazon S3 by our content creators with minimal effort. This project finally came to fruition a few weeks ago and we’ve been tweaking and tuning it since then, getting everything set up and running correctly.

We decided on using Jekyll for building the static pages because of the community behind it and the sheer amount of support poured into the project. The plus side of going with Jekyll is that there is also a tonne of readily available and easily digestible documentation for those that don’t quite understand what a “static site generator” is. Liquid, the templating engine for Jekyll, was built by Shopify (?another Canadian company, woo!?) and is very powerful yet simple to use and extend.

Amazon AWS S3 + Cloudfront was a good choice at this point because the nature of S3 makes hosting static HTML files super simple and adding Cloudfront for caching on top allows us to serve extremely fast pages.

Seperation of Concerns

…or Why Content Creators Are People, Not Computers

Moving our landing pages out of our main app has allowed our marketers and content creators to move quickly, create new marketing avenues, and deploy them in a matter of hours! We’ve also built internal tools that allow the same people to be on the command line as little as possible because who wants to remember what eight different commands need to be written in order to get a new landing page up. Having the isolation from the main app also allows for a point of failure to be removed from the engineering side when deploying.

So the moral of the story is: if you’re looking to make the switch to split out your landing pages from your main app, we strongly advise you do so. After all, your writers already have to operate under one set of arcane, cryptic, and frequently ambiguous rules, why add another?

Share this post
Tweet about this on TwitterShare on Facebook

Leave a Reply

Your email address will not be published. Required fields are marked *