With the exception of Standard and contract projects, I generally don’t build WordPress themes for release.
I tend to favor plugins because I’m attracted to the functionality that they are able to introduce to the core WordPress application and, frankly, I don’t have the design chops required to produce a theme of high enough quality.
Simply put, I try to focus on what I’m good at doing so others can do the same.
Last week, I talked about the problem of offering support for free WordPress plugins, the challenges that I’m currently facing, and ultimately what I’m aiming to do about it.
So in keeping consistent with trying to share my general thought process on both plugin development and moving to a better business model, I thought I’d also share some thoughts on building WordPress plugins.
Building WordPress Plugins (Note: Plugins Are Software)
I think one of the most important things that developers should note is that plugins are a form of software and should be treated with as much care as a larger-scale enterprise application.
Obviously, I’m not saying that you need expensive tools to get the job done, but development – regardless of how large or small – is all about problem-solving at its very core.
To that point, there are several things that I try to do with each plugin I work on – regardless of if it’s commissioned or freely available.
1. Know My Problem
Since plugin development is about solving a problem, it’s important to have an understanding of the problem, right?
This seems like common sense, but if you look around at a variety of the plugins that are out there, it’s almost like they try to do a handful of different things, and only do it in a half-baked manner.
I’d rather release something simple that does one thing well, than release something that does 10 things sort of.
2. Filter Feature Requests
Once there’s a clear understanding of the problem, it’s really easy to determine if a feature request belongs within the context of your plugin or not.
Case in point: In my most recent update to Tag Sticky Post, I responded to a forum post that clearly detailed the use case the user was having. It made perfect sense in the context of the plugin, so I ended up adding the feature.
But too often, I think developers find it easier to throw the kitchen sink at their plugin and introduce almost as many feature requests as possible. This ends up blurring the vision of your plugin and ultimately raises the question of exactly what problem – or problems – you’re now trying to solve.
It’s okay to say no. Best case scenario, you end up writing a new plugin to fulfill the need.
3. Start Lean
For those of you who have read some of my posts, you know that I’m a fan of what I call a “strong 1.0.”
Simply put, I think a 1.0 should be as close to an MVP as possible without actually skimping on features or aspects that make it feel like a fully developed product.
I say that because sometimes I think that people equate MVPs and prototypes, but they’re not the same thing. MVPs should be the strong 1.0 that delivers values to your users.
Prototypes are what you and your team work on before moving on to an MVP.
Anyway, I believe in starting lean because it gives you the clearest vision and the strongest foundation off of which to continually build your product. If you try to anticipate things from the beginning, you’ll likely miss the mark.
Solve one problem, solve it well, and users will offer feedback. Properly filter it and your work will continue to mature.