Happy with Headless: Does Your Organization Need to Rethink How You Manage Digital?

What is headless? 

A headless website answers the question, “Why are we asking our CMS to do both backend editing and be responsible for serving that content to users?” One of the things you learn early in software development is to try to give a piece of code only one job (The Single Responsibility Principle), and it’s software’s version of saying “allow people to do what they’re good at.” Headless is a way to let each piece of website software do what it does best and nothing more. You know what WordPress is really good at? Content. They’ve made it easy for a wide swath of users with an equally wide swath of tech-savviness to contribute content to a website. You know what WordPress isn’t great at? Showing that content to users. But many organizations are, justifiably, unwilling to ditch WordPress entirely. They (and certainly their developers) grin and bear the parts that WordPress doesn’t do as well. Headless is a way for these organizations to continue to use WordPress for content development while handing off the ‘showing’ of that content to systems that are much better at showing it. It turns out that a headless approach is good for everyone: developers, users, and you.

Headless is Better for Your Developers

Older, grizzled developers know all-too-well the absolute terror of changing live files or making database schema changes. The terror is somewhat better these days with git deployments, instant rollbacks, automated testing, and staging / production workflows, but while it is better it is by no means easy-breezy. We still follow the Two-Person Rule all these years later: “I’m going to push. Do you concur?” 

Headless really makes this easy. You make your changes, you test them, you ensure everything is hunky dory, and you push the front-end of the site up and breathe. Content doesn’t have to change, you’re not making file changes within your CMS, and the database is safely sitting behind your API where a stray bug can’t get in. Everyone is doing their one job well. 

Headless is Better for Your Users

Users don’t like slow websites. Few things are more frustrating for web users than sluggish, unresponsive websites that cause the “Is it the website? Is it my connection? Is it my computer?” dance to begin. Nobody likes that dance, and if they find out that your site is the culprit, users will find other means to access the content you’re offering. Headless websites are super fast. By separating your content and the presentation of that content, you can heavily optimize that presentation so that you provide the fastest possible experience for your users. 

Headless is Better for You

Headless allows you to devote resources to development not infrastructure. If you do headless right, your choices of hosting are effectively limitless. AWS, Heroku, Linode, a spare box you have in your closet are all good options (Well, except for the closet box. Please don’t use a spare box in your closet). And, it’s cheaper. All that infrastructure costs money. Big infrastructure costs big money. If you don’t want to spend big money but still want rock-solid performance, headless gets you 90% of the way there out-of-the-box. Plus, if you have a few different endpoints for your content (think website, app, and internal tool), you manage that content in one place with a headless approach. 

Security-wise, headless is a no-brainer. By untangling your apps from the content that feeds those apps, you can better lock down a bad-actor’s ability to do major damage. When we worked with the Student Freedom Initiative (a non-profit backed by Robert F. Smith that is looking to put an end to the student debt inequity seen at HBCUs), the move to a headless approach allowed for a better fit with internal security protocols while still giving the team the ability to manage their own content.

Headless is the Future

There have been a lot of ‘paradigm shifts’ over the years that promised better performance than WordPress, Drupal, Rails, or Django could provide. Over time, though, organizations have always migrated back to the tried-and-true solutions because the new way of doing things just wasn’t as good. Many never made the change in the first place because of the training necessary to move from one system to another. Headless, though, seems to be sticking. It’s sticking because those organizations get to keep their old CMS and enjoy the benefits of a fast, secure, reliable site and because developers really like the separation of concerns headless allows. Users, it turns out, really like fast websites.