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 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.
A few months ago we started a project to move our landing pages out to their own Github repository so they could have their own procedures for deploying, ease-of-use for copywriters, 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 fine-tuning ever since, to get 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, woot!) – 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 allows us to serve extremely fast pages.
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 let’s be honest – who wants to remember what eight different commands need to be written in order to get a new landing page up? Having independence 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 this: if you’re looking to make the switch to split out your landing pages from your main app, we strongly recommend you do so. After all, your writers already have to operate under one set of arcane, cryptic, and frequently ambiguous rules – (*cough* grammar *cough*) – why add another?
