Should web developers use WordPress for the websites that they build for their clients?
WordPress is a robust content management system with a well-built core, intuitive user interface, and vibrant development community. Web developers should keep WordPress on top of their list when selecting a platform to power their clients’ websites.
The fact that, as a web developer, you can build a website for a client from scratch doesn’t necessarily make it the best thing to do for the project or client. And, in this post, we’re going to talk about why.
A content management system can give you a resilient and extensible backbone to build websites on, significantly reducing most project’s development and maintenance costs.
Just like you’d consider using an email delivery service like Amazon SES or Mandrill to trigger transactional emails for an app, you may want to consider adopting—and building on top of—a CMS for a website.
Though much can be said and written about the advantages and disadvantages of doing so, especially when compared to building a website from scratch, there are times when reinventing the wheel doesn’t make technical and economic sense, and that’s when the name “WordPress” usually comes to mind.
WordPress Is Just a CMS
It’s important to remember that WordPress is just a content management system (CMS). As adopted and praised as it is, the name itself shouldn’t be the main reason to decide to go with it or not.
After all, a CMS is nothing but the technical backbone that reduces the time and effort required to build dynamic websites.
Ideally, it should also make it easy to use and operate that website, especially when it’s been chosen correctly and implemented well (or, as the folks who implemented the ITIL framework tend to say, an IT system must be fit for purpose and fit for use).
There are many upsides to WordPress, that’s for sure. For starters, it gives your client access to the best drag-and-drop editor, Gutenberg, of any CMS on the market. WordPress also has an intuitive admin panel and offers unrivaled extensibility through themes and plugins.
As a developer, a major perk of WordPress is that you get to build on top of a core platform developed and maintained by Automattic (a team that pioneered the web and defined the meaning of remote work). You also benefit from participating in arguably the most vibrant and helpful community of any website-building platform.
Of course, WordPress has a fair share of downsides to it.
For example, choosing WordPress will vendor-lock your client’s website to the capabilities and constraints of the platform and tie its evolution to that platform’s roadmap, which can be a good and a bad thing. It also makes their website vulnerable to well-known security flaws and dependent on updates for fixes.
As a developer, WordPress limits you to the LAMP stack as well as the development, testing, and deployment tools available to the WordPress community. Naturally, to get good at it, you’ll need to learn the WordPress Codex by heart or at least become able to search and navigate it skillfully.
Unless there’s a compelling reason to do otherwise, your choice of CMS should be determined by your client’s business needs and, when working with bigger companies, their technical requirements.
Then, that choice should be influenced by a comparison of the solutions on the market that best meet them (whether the outcome of that comparison is weighting heavily toward WordPress or not).
What Does Your Client Need?
Always consider your client’s needs before you start solutioning.
Are you setting out to build a basic, brochure website for a local business? Or have you been asked to create a media outlet to be used by a dozen or so staff writers and read by tens, maybe even hundreds of thousands of readers a day, requiring you to think about WordPress at scale?
Will you be developing against a set of mockups for a fancy, modern design that won’t change all that much and that will only be updated by professional designers and edited by front-end developers over time?
If the answer to the above question is “yes,” you may want to consider a headless WordPress implementation to decouple the front-end from the back-end for more than one reason.
Does your client want to be able to create and edit pages and posts on the fly, by themselves (or their marketer, or their marketer’s intern), which will require you to think about Gutenberg compatibility, perhaps even compatibility with a popular page-builder plugin already out there?
How simplistic—or robust—content management capabilities does your client need in their admin panel? Are we talking about creating and editing posts on a small blog, a full-featured magazine with multiple types of articles, an online store with categories, search, and filtering?
How does that influence your choice of custom types, taxonomies, fields? Should these only be created and managed by technical users who can edit code (and, if yes, what’s their level of experience), or should power users be able to do this from somewhere in the admin panel?
What Does Their Tech Stack Look Like?
Suppose you’re working with a three-person startup whose team just got VC funding and quit their jobs to get together.
That small startup team will have significantly fewer technical requirements than a thousand-person corporation with a picky Enterprise Architecture team and an established tech stack.
When deciding whether or not you should use WordPress on a client project, think about how WordPress would fit—or not—in the context of their existing tech stack.
What is this company powering its website with today? Are they looking to move away from it, update it, or redo it? How close or distant is it to Apache servers, the PHP programming language, sequel databases?
Do they have a standard teck stack, architecture design patterns, solution prescriptions, or any other non-negotiable practices that specifically require—or forbid—the usage of WordPress as a CMS?
For example, a large corporation may already be using Adobe’s Experience Manager or Progress’ Sitefinity and only be looking to revamp its implementation of them rather than migrate to a different CMS such as WordPress.
Say that you’re working with a company that does want to use WordPress. Do they require you to use a theme skeleton, for example, Underscores, a development framework such as Genesis, or any plugins that match their team’s existing skillset, like Advanced Custom Fields?
Last but not least, are there any watch-outs that you need to know about in terms of licensing and commercial vs. non-commercial use of the libraries, frameworks, and tools that you’re about to leverage?
All of the points above are good to consider when you’re discussing the project with your client to decide whether to use WordPress or not. And, if the answer to that question is “yes,” going through this process will help you make critical implementation decisions in a better-informed way.