The CMS is Dead. Long live the CMS

Here at Beach, with my team at Nuwe, and in fact, at every place I've ever worked, we always have the same debate when it comes to building a new website.

Which bloody CMS do we use?

Over the years, we've tried everything from Wordpress, Drupal, Squarespace, custom Codeigniter MVC app, custom Rails app... and we came all the way back to static.

We've been building static single page sites for a while now, which for value proposition testing and product sites that works just fine. But what about when you want something more? An e-commerce site perhaps, a blog or news site or a larger marketing site.

Whatever method we chose, whatever the tech, it never felt right. There was never an occasion that every stakeholder in the team could say they were happy. From a developer perspective, we were always "hacking" the set of pre-defined characteristics to bend it to our will - whether it was extending the wordpress content models or injecting javascript into squarespace templates.

When we had more freedom, such as building out our own rails-based CMS, there was never enough time or budget to do the job properly - and even if we did, we'd just be contributing another fixed architecture platform that would inevitably change beyond recognition, the next time round.

The Post-CMS Era

There's been quite a groundswell of belief over the past couple of years, that we've been doing it wrong. We've been making servers do all sorts of stuff they shouldn't be doing.

To my mind, “post-CMS” means the disaggregation and, in many cases, elimination of the component parts of a CMS. What remains is simply the tools we need to for a particular project and nothing more.

Over the past couple of years, this premise has given rise to a growing community around static tech. Static site generators are mostly the playground of developers, due to the need for some technical chops. Often involving the use of the command line, config files, git workflows and repositories. Our very own Hammer serves to simplify much of this process, but alone, it's not enough.

So, as we consider the quote above, it leads us to ask just what are the tools we might need for a particular project?

Static Site Generator (e.g Hammer, Jekyll, Middleman, Roots) - for building our pages, templates, styles, js and compiling our project. 

Static Site Hosting (e.g. Forge, Netlify, Github Pages) - for serving our site in the fastest and cheapest way

Content API (e.g. Contentful, Prismic, Osmec, Wordpress!) - for slow data

Data API (e.g. NuweParse, Firebase) - for medium, fast and ephemeral data

On their own, each of the example services mentioned here are really great. For each, there exists an equally awesome alternative. Each one is similar, but also different in many ways (ruby versus javascript, command line versus GUI, open versus closed) - the point is, each on their own gives the web designer and developer the option to choose their preferred tool for the job, for their skill set and the workflow of their team. 

But, in the context of this post, we're really focussed on how these components of the New CMS work together.

So we're imagining a different way, which over time, could be a better way and we think perhaps, could become THE WAY. Here's a glimpse of what that could entail...

In a nutshell, here's how it works.

  1. You build your templates using the simplest, easiest to use front end technologies - html, css and javascript. On the advanced side, you can use all the front end development tools you love - pre-compilers, package manager's, templating languages, javascript frameworks.
  2. You create your content in an easy to use, nothing to host, secure and maintain content admin environment.
  3. When either your templates get updated, or new content gets published, the system rebuilds your pages and publishes them statically to static hosting, with super fast global CDN. 

It wasn't hard to imagine, if I'm honest. For one, fellow static advocates and the creators of the roots static site generator, Carrot Creative, posted this article last year. Here are my initial concept notes as a result of reading it. We're certainly not the first to both see the potential and start tackling the problem.

There's nothing to maintain. Nothing to configure. It's secure. You can make it as simple or advanced as you like. The server isn't being used as a html generating work-horse. You're not protecting a server from malicious behaviour.

Where there is a backend, it's simple. No Linux, Apache, MySQL or PHP knowledge needed.

For your end users, they get served the fastest sites that are already web scale and with very few points of failure.

The great thing is, here at Beach, we have enough of the pieces that can make a system like this work and not just for Developers. But for everyone.

The Static CMS.

Powered by Hammer, Forge & Contentful. 



Contentful is a hot startup, founded in 2013 and growing like mad. If you don't know who they are and what they do, Contentful is an API-first Content as a Service platform. 

You administer your content using their cloud hosted service and with their API, can serve the content wherever you need it.

Their admin UI is flexible and intuitive, allowing you to build a content model that works for you, instead of hacking around the default content models, you'll find in open source CMS's like Wordpress (Posts, Pages etc.)

They're not the only service of its kind. You could also check out Prismic and Cockpit and we'll likely add support for these services in the future.


Hammer comes into its own here, but perhaps, not as you know it. We've integrated Contentful into the Hammer compiler, so you can build your sites statically using our popular Hammer OSX app. That would be cool enough, you could then build your site and upload it to a static site hosting service like Forge easily enough.

But, this is a CMS. We don't want to have to manually upload a build each time. No, no, no that just won't do.

So, we've brought the power of Hammer to Forge.


You will be able to upload a raw Hammer project to Forge and let Forge handle the build and deployment of your site.

You can tie this into the Github auto-sync feature, whenever you push an update to your templates to your Github repository, or when you add or edit your content on Contentful, then Forge will automagically rebuild and deploy your site.

Lest we forget...


When you're working locally, Anvil takes away all the issues you might find with cross origin resource sharing and file:// system asset paths as well as making the whole process generally better, cleaner and more fun.


Suddenly it all becomes clear. This is the way it should be and this is why we love what we do. I'd love to hear your thoughts and experiences in with CMS's, with managing content sites, working with clients and your aspirations for a better solution.

In the coming posts, I'll show you how we've prototyped this, how we've started using it to build product sites out in the wild and how you can get started building content managed static sites.