Avoiding Plugin Lock-In

Plugins are wonderful tools. As great as WordPress is on its own, the platform would be nowhere without the countless plugins that keep the ecosystem going. Plugins are so normal to both WordPress developers and users we often don’t think about them. Should we?

Why Do We Use Plugins?

What makes plugins so fantastic for the community is they allow users to add functionality to WordPress that is specific to them without burdening the larger project with features. The maintainers get to focus on the big picture, while the subset of users with particular needs is still served. It also enables non-technical users to add features without being dependent on developers to build things for them. These are both good things, but I find myself questioning the hidden costs.

Early on in my WordPress career, I was leery of plugins. I was still very new to web development and wanted to learn how to do everything and anything I could. Far, far too often my Google searches for “How to do X with WordPress” would yield nothing but articles on how a plugin solved this problem for me. These were not complex tasks, but simple concepts that required only a couple of functions. I found myself unable to learn new skills because the focus was on premade solutions.

The cynic would think this kind of approach was a sales tactic. Getting people dependent on the software they need to run their business is a common business model. Bill Gates is one of the wealthiest people on the planet for a reason. But this is WordPress. Most of these articles were talking about free plugins. The focus was not on making money but on providing simple solutions to simple problems.

Enter Technical Debt

Technical debt can be a bit of a nebulous concept, especially in a project like WordPress that is constantly changing and improving. The core idea is that choosing a simple solution that mostly solves your problem instead of a more complex (read: expensive) one has hidden costs you have to pay later. WordPress plugins are a prime example of this concept, and because so many plugins are free, the “cost” is minimized. You pay with time instead of money.

When a WordPress plugin is abandoned, you find another option. That’s the cycle. The market is filled with solutions to most problems. But what happens when your site is coded to work specifically with one solution? If you can’t code, how do you fix your now broken site? You were trying to avoid paying someone to build things for you, but now you can’t.

Eliminating Dependencies

I’ve built sites like this. All of us have. We get so used to certain plugins in our toolkit that using X plugin is just “how we do things” now. For developers that don’t actively maintain the sites they build afterward, this is dangerous. Making your code someone else’s problem may help you sleep at night, but it’s a bad look for the community and harms WordPress as a whole.

A lot of these issues seem small. Reconfiguring a theme to use one forms plugin over another is just changing a function call or two. Most of the time, that’s all we’re talking about. The financial burden is small, the end-user doesn’t mind that much, and we all move on. Other times, however, the changes and costs can be catastrophic. Can you imagine how expensive it would be to strip out Advanced Custom Fields from a theme? You might as well start over because it would be faster.

Gutenberg Makes This Worse

I absolutely love the Gutenberg concept. The editing experience is so much better that I can’t imagine going back. But the rise of Gutenberg, or the Block Editor if you want to be official, has also increased our dependencies. As the concept of the blocks has matured over the last year, companies have built businesses around them. They sell huge packages of 30 or more blocks, giving you even more tools to use. It seems great on the surface and comes at such a cheap rate that it’s really, really hard to turn down. If you look past the immediate value proposition though, you’ll find you’re only setting yourself up for more technical debt.

If a block you love to use becomes unsupported or has a security vulnerability, you’ll find a new one. Not that big of a deal, right? But what if your new block has a different markup structure? It looks the same in the examples you saw, but when you drop into your site, everything looks broken. How do you fix that? If you’re a non-technical user, you pay someone. If you’re a developer yourself, you build your own. Either way, you’re paying.

For a non-WordPress example, take the issue I’ve had the last few months with my diabetes management app. I picked it because it provided me with several features to keep track of not just my daily blood glucose, but also my estimated A1C. Over time, the app developer monetized those free features. Each update would take away a small feature and make it part of the premium version. I could avoid paying for a while, but eventually, enough features were taken away that I abandoned the app entirely.

Shifting The Burden

Developers need to make money. The software shouldn’t necessarily be free, but the bait and switch game is very problematic. What happened to me with my diabetes app has happened to me with WordPress plugins. They weren’t vital enough features that I had to switch plugins personally, but it has happened to clients, and that’s the problem. WordPress Developers are placing an undue burden on our clients, both technically and financially by locking in plugin usage when the burden should be on us.

There are two ways this happens – intentionally and unintentionally. You may have done this yourself and not even realized it. You have a developer license for a plugin that allows for unlimited installs, so you put it on a client site without thinking about it. You’ve just locked the client into being dependent on your license.

Intentional Lock-In

In that scenario, the question of motive is pertinent. If your goal is to establish a larger financial relationship with the client, that’s fine. If you are not transparent with the client about that? That’s not fine. Intentional lock-in is a valid business strategy and can be profitable and helpful to the client. Knowing someone has their back when things go wrong or changes are needed is valuable – if the client knows the situation ahead of time. If a license needs renewing and you hit them with an unexpected cost, you’ve just betrayed the client’s trust.

The solution to this problem is to lay everything out in advance. Tell your client what plugin you are choosing, why you are choosing it, and the cost. From there, have them buy the plugin and own the license. This gives them the freedom to move away from you if the relationship changes without you becoming problematic. If you are sharing an unlimited license, make the terms clear in the contract that their use of the license is contingent on your continued business relationship. Also, make sure they know the costs should they chose to go in another direction. While it’s not the best scenario overall, at least everything is out in the open. You’re allowing the client to make an informed decision instead of being blindsided when an issue comes up.

Unintentional Lock-in

The more problematic situation is when you lock a client in unintentionally. You picked a plugin for forms and wrote the custom theme to use that plugin’s custom functions. From a cost perspective that makes sense – you can move fast and charge less money because you always do things a certain way. But if that plugin becomes an issue, you have to strip it out. That costs time and money, something you or the client may not have.

The solution here, particularly as it relates to Gutenberg blocks, is to not rely on commercial or free plugins. If it does not come with WordPress by default don’t rely on it. WordPress announces their changes well in advance and provides testing versions ahead of releases so you’re not caught off guard. Building custom blocks for clients is more costly and time-consuming but prevents future headaches. Plus the client gets a solution that fits their exact needs, inside of one that mostly works but could be better.

Transparency In All Things

In the end, the choice is yours. I can’t force you to run your business a certain way. What I can do is remind you of the importance of transparency. It builds trust. It engenders loyalty with clients in an age where that concept no longer seems to exist. If they trust you to get the job done, they’ll keep paying you. Clients trust developers that keep them informed. They want to know how you’re spending their money, at least as it relates to the project.

When you’re making decisions about how to build something, don’t immediately reach for the easy, free solution that does most of the job. Consult with the client. Make sure you both understand the risks, the costs, and the long-term effects of the decision you’re about to make. Be transparent, and you’ll both be better off.

Adam Soucie
Adam is a WordPress developer based in Orlando, FL, and the founder/CEO of Impossibly Creative. He is a member of the WordPress Orlando organizing team and a frequent speaker at the WordPress Orlando meetup.


  1. At some point you have to rely on some tools though, right? We use WordPress, which already is something that could change for us, as it did for many people with v5.0

    It’s good to let clients know the tools that are being used, but there’d end up being something that goes bad eventually on a site.

    1. Absolutely. There are some plugins I consider indispensable, but when I use them with clients I make sure they’re aware of the costs associated and why I consider it vital to the project. Far too often, that’s never made clear to clients who come to me with plugins that are way beyond expired and aren’t aware that licenses even exist.

Leave a Reply

Your email address will not be published.