For those unfamiliar with WordPress; WordPress is a piece of software referred to as a Content Management System (CMS). Its primary role is to literally manage the content of a website – to store and display content for users and administrators in a human-readable way.
In building a WordPress website, there are generally three routes you can take:
1. Using an existing theme from the theme ‘library’ on wordpress.org and plugins from the plugin repository. Some articles across the web refer to these as “WordPress Customizers”.
2. Using an existing theme or page builder such as Divi or Elementor to build a custom website. Sometimes a developer/agency may also use a pre-developed theme. One which they use across all their client’s websites, but is customised for each client. Where a custom solution can’t be built due to gaps in their knowledge, they would generally find a plugin to fill in these gaps.
3. Building a completely custom theme for their clients. There may be some plugin use for tasks such as SEO and reworking the backend of the site to make it more user-friendly, such as Yoast SEO, or Smush (image optimisation), but generally the website’s build process and structure is entirely focused towards coding.
Because of the flexibility in building a website with WordPress, there’s a clear market saturation with those who call themselves developers. Even a quick Google search for ‘how many WordPress Developers are there?‘ returns a fruitless search for even a rough figure. Personally, I think the main reason for this is that anyone who builds a website using WordPress will likely call themselves a WordPress Developer.
Enter the “implementer”.
Tom McFarlin first looked at the difference between WordPress developers and implementers in an article on his website in 2014. In his article, one comment by Julien Maury summarised the difference between Implementers and Developers (programmers) perfectly:
“An implementer will say first “ok I’ll check if there’s some good plugins to do that” whereas a developer will say first “I’ll check if I can do it”.
Both of them are good resources for project owners. Not all project[s] need developers but there are project[s] that should not be handled by implementers.”
The power of an informed choice
Much like Tom and Julien, I think it’s important to consider the difference between WordPress developers and implementers, if only to empower clients to make an informed choice over which type of content management service they actually require.
The importance of making an informed decision becomes starker the more significant the job in hand. If a retail client required an e-commerce solution to manage millions of pounds in revenue, which is connected to their customer relationship manager (CRM) and powers their entire company, in most cases it would be more suitable for them to use a developer to spearhead the project.
That’s not to say that implementers wouldn’t be able to successfully complete the job. It’s about how the project is tackled, and a solution is found. As a general rule-of-thumb; the more complex the job, the more complex the solution.
Similarly, if an independent retailer needed an online presence to support their offline retail business, it would be entirely reasonable for an implementer to take on the project with minimal risk of the system collapsing under the structures put in place.
Communication is key
In the long run, clients know what matters to them the most. WordPress Developers and Implementers know their limitations, so clarity in conversation is key.
If a developers/implementer is unable to carry out the work asked for, they should be upfront with the client, but in-turn that requires a client to be clear about their expectations on a project.
Communication is key, and unfortunately for a client, the litmus test of quality only occurs when moving from one provider to another. If they haven’t had a clear conversation with the developer or implementer, it becomes a watershed moment that exposes any cracks that might come as a result of their initial developer’s choices.
The BLT approach
At Brave Little Tank, we may use WordPress, but this serves only as a means to an end. Our team are happy and willing to build custom features for clients, such as lead management systems which are integrated with 3rd Party services. Working with API’s to extend your website functionality and all of our solutions are transportable to other providers*.
Only making use of quality 3rd Party plugins to keep costs low and avoid reinventing the wheel. Each project is looked at with fresh eyes, and while the alternative to a 3rd Party plugin might be possible, it wouldn’t necessarily be beneficial for our clients.
We are open, honest and fair in our approach, to enable prospective clients to make that informed decision.
Build. Measure. Learn. Repeat.
*we reserve the Intellectual Property rights on some of our products which, may incur a fee to purchase the right to use the code with other providers. All protected code remains property of Brave Little Tank.
