WordPress Plugins: Do you need them at all?

Plugins are one of the best and worst things in the WordPress ecosystem. They can increase development experience and also decrease to the lowest level. They can make us happy, and cry. So should we use them?



Plugins are like magical tools that can make your website do amazing things. They help you add cool features and make your website look and work just the way you want. But using plugins isn't always easy – you need to know when and how to use them.

In this article, I'll explain the idea of clean architecture and how it affects your business. I'll help you figure out when plugins might not be the best choice and give you practical tips on deciding when to use them. By the end, you'll know how to use them in a way that will make your life easier, not harder.

So, let's take a journey into the world of plugins and explore why thinking about this topic can help you make your website even better – step by step.

What is Clean Architecture?

Software architecture is all about the direction of dependencies.

Let's assume that you're building a house where you spend the rest of your life. You want to have the ability to choose and use solutions that match your requirements, your expectations and which are not dependent on anyone else but you.

You probably don’t want to change the layout of your kitchen (the core) due to the Fridge X (implementation detail) that doesn’t fit. You’ll just find the fridge that will fit there. Of course, sometimes you will have to find a compromise, but mostly you’ll want to do it in your style.

That's an example of the clean architecture of your life: You're in the centre. Everything else is around this. Why it is good architecture? Because the dependencies are directed in correct way - towards things that are most important.

And the same approach should be used when you build applications that solve your business problems. Your problems, your needs and your requirements should be at the centre with the highest possible independence level. Plugins are just implementation details so you probably don’t want to change your business needs because external solution requires this.

So if your business needs are at the centre, you should build solutions around your then rather than around plugins.

How architecture impacts your business?

Let's say you're building a hotel room reservation system for a client. The client's business needs are simple - guests should be able to reserve a room and select the number of people in their party. You decide to use a free plugin that provides this basic functionality.

However, as the client's business grows, you realize that you need to offer more customized features, such as different pricing for adults and children, and the ability to restrict bookings during holiday seasons on certain weekends. Unfortunately, the plugin you used doesn't support them, and modifying behaviour without altering its core files is difficult.

As a result, you start adding more and more business features on top of the plugin to fit your client's needs and after a short time, you've become too reliant on it. Let’s assume that the author decides to switch to a paid license, which costs $1000 per week. Since the system is now heavily dependent on the plugin, there is no choice but to pay the fee. The worst-case scenario happens when the author abandons the plugin, leaving your business without updates.

This example highlights the biggest problem with plugins. You are dependent on someone else's work and decisions, which can potentially harm your client's business. If the plugin author implements faulty changes, the business will suffer. If there is a data leak due to poor security, the business might be impacted as well.

In other words, the business needs should be at the centre of your software development strategy, not plugins. By building solutions that match business needs, you gain more control over the outcome and ensure that your business is not dependent on the decisions of others. The business is at the centre, and your software should reflect that.

When plugins might be a bad choice?

Using plugins in your projects can be a tempting shortcut, but it's important to understand the potential risks it entails when the system grows. While those can add useful features and save development time, they can also make the system difficult to modify or generate more unexpected problems over time.

Of course, it's unlikely that you can completely avoid external dependencies, but you can try to minimize the system's reliance on any of them. In my experience, many projects that have relied heavily on plugins have encountered scalability and flexibility issues as they have grown.

You might think using popular plugins won't harm your system, but I used to believe the same until I experienced the issues they can cause, even for simple tasks. So, here are the top reasons why I avoid using plugins:

  1. Database Optimization: The plugin works well with a small database, but when it grows, it becomes unusable even in the simplest things. Example: Yoast
  2. User first, developer second: Plugins are overloaded with many features that you mostly won’t use. With features that look instead of work well. Example: Ninja Forms
  3. Front-end Optimization: Most of the plugins load tons of CSS and JS that are slightly used. Those loads tons of code for providing super simple things.
  4. UX: The plugins are something that make dashboard hell when it comes to UX. Tons of notifications, widgets, columns, different settings layouts what makes clients lost there.

To reduce these problems, it's important to prioritize business rules by creating the most crucial parts as custom solutions to match exact needs and using plugins as tools rather than the foundation of your solution. It is important to design the system in a way that allows changing plugins without touching your core business requirements.

How to decide about plugins usage?

I don't want to say "don't use plugins at all" because I don't mean this. You can use them as much as you want. But please always be mindful of their potential impact on your project, and always weigh up the benefits against the risks. So how to decide when and when not to use plugins in your app? I’ve created five rules that help me in this.

#1 Focus on the Business.

Try to build the system around your business rules rather than plugins. If the booking is the most crucial part of your success put more money and effort and build a booking calendar from scratch. It will be easier to make changes when the business grows. Do not try to hack plugin behaviour to fit your business requirements all it takes. If you need to do this in the first stages you can be sure that it will become even worse when the project grows.

#2 Avoid "plugins as default choice" approach.

Try to implement some requirements yourself especially when those are really simple. It ensures that the code does only things that are really needed and that’s super useful when things don’t go as planned. There is no need to install a plugin for adding GTM when you can do it yourself even simpler in the code.

#3 Have a clear logic reason for using plugins.

It is good to use plugin-driven development when building MVP because quality is less important than time. It is also fine to use plugins that you really trust. But if you install a plugin without putting any effort to check how can you do it yourself - the reason is laziness - that’s wrong.

#4 Be responsible for your decisions.

If you recommend using a plugin for a specific feature - you’re responsible for this no matter if someone else has created it. You can’t clear yourself in case of problems blaming mainly plugin X. Client is not interested in it if you recommended and decided to use it.

#5 Use plugin as tools.

If you use plugins, try to use them in a way that will allow easy switching when something changes. Try to use some of SOLID principles as your weapon.

What will you get in return?

Adopting a new approach can be overwhelming, especially in the beginning when costs may seem excessive. This is because many elements need to be developed from scratch, resulting in a higher price point. Moreover, the WP market is filled with cheap alternatives that implies plugins and poor architecture, allowing them to complete tasks much cheaper. While it's true that WP competition is high, but… Just try!

Create your own workflow, use the KISS principle, collect ideas, and snippets, build your components library, improve them with every project and make things easier over time. After a few projects, you’ll have building blocks that you’ll be able to create highly scalable and plugin-free architecture. As a result, you get the following items:

  1. Business rules are less dependent on external factors.
  2. You’re not responsible for someone’s else work.
  3. Your system is better prepared to change.
  4. You can sleep better.


Building projects without relying heavily on plugins has been a game-changer for me. It has simplified development and sped up the process, but it has also improved a sense of responsibility in me and my team. Clients appreciate this approach and it has helped us gain their trust.

Don't get me wrong, plugins have their place, but minimizing their usage and being mindful of their impact can make all the difference in building scalable, big and successful projects.


How satisfied you are after reading this article?