In my early plugin-building days, I used to think more features meant more value.
If a user requested something, I added it.
If another plugin had a setting I didn’t, I felt like I was behind.
If I saw a competitor with a dashboard full of toggles, I thought, maybe I need that too.
But over time and through maintaining real plugins used by thousands of people, I learned something the hard way:
More features don’t make your plugin better.
They make it heavier, harder to maintain, and harder to use.
Every feature sounds useful in isolation.
The problem is, they pile up.
And soon your clean, focused plugin becomes this bloated toolbox with too many switches, too many edge cases, and too many things that can break.
I’ve been there.
I’ve had support tickets that only existed because I added a “cool” setting that three people used and fifty others accidentally triggered.
I’ve had to debug things that I didn’t even need — all because I wanted to match a checklist I saw in someone else’s plugin.
So now, I take a different approach.
If someone requests a feature, I don’t say yes right away.
I sit with it.
I ask:
- Does this solve a problem for a large number of users?
- Is this aligned with the core purpose of the plugin?
- Will this feature still make sense six months from now?
- Can this be handled by another plugin, or with a snippet?
And most importantly:
Would I want to maintain this feature myself?
If the answer is no, it’s probably not worth adding.
These days, I focus on clarity, not quantity.
I’d rather have a plugin that does one thing really well than a plugin that does ten things halfway.
Because in the end, people don’t remember how many features you had.
They remember whether your plugin worked — and whether it made their life easier.
That’s the bar I want to meet now.
Leave a Reply