Whilst in essence it does boil down to writing some code and selling it, creating commercial software is really no easy task; as with any enterprise, software building with a view to selling has its own unique issues and important things to consider.
For example, before you even start writing the code, you need a ‘business model’ for your software – are you just going to sell the plugin outright, or will you attract potential customers with a free or cheap ‘lite’ version and then sell a boosted ‘pro’ version with additional functionality. This is a very popular route, but it needs to work for you; things can quickly spiral and become very complicated. You don’t want to dilute your ‘pro’ version by giving away all the core functionality in ‘lite’, and equally you don’t want to undersell all your hard work with an underwhelming intro to what is really some truly clever software. You also have to multiply all the coding, pricing, branding and functionality issues involved in developing a plugin by two – and you thought one was hard work!
To try and make the slightly daunting task of selling the fruits of your labour a little easier, I’ve come up with this list of the key things you should think about. Working your way through this list, if nothing else, will help you organise your thoughts and feel reassured you haven’t forgotten anything crucial.
Pricing is one of the most important decisions you’ll make in your software selling journey, and there is a lot to consider: price points, pricing model, service/license tiers, and limitations, to name a few.
Standard practice these days is to sell a one-year license, including support and updates, with various tiers allowing increasing numbers of activation sites. This will obviously depend on the nature of your specific plugin though, as site based limitations aren’t always relevant, so you may need to impose limits on other features; some plugins may require more ongoing support than others, which may also need to be factored into your service provision plan. When it comes to pricing, flexibility is key – if something isn’t working out, change it.
I follow very clear and set processes in coding and development, which help to make complex ideas fairly straightforward to realise. Sometimes, though, simple tasks spiral, and what seemed like a quick update or enhanced function can take you right back to square one and require you re-think the specification of the entire plugin. The big cost of unexpected complications is time, so no matter how simple you think your development will be, make sure your timeline has some additional slack for any unforeseen delays, a buffer to safeguard your release date.
In any commercial enterprise, marketing plays a huge role. Gone are the days when you could simply create a good product, put it out there and wait for sales to snowball as word spread. Now, you need to be thinking about marketing from the get go, and marketing is essentially expectation building – making your potential customers aware that a new product is coming, getting them excited about it and convincing them it’s going to be great. You need to do this, and do it well, if you want customers to buy it, but you also need to make sure that you can deliver on your promises. This is why that buffer in your timeline is so important – marketing is about momentum building, and nothing kills momentum like a constantly pushed back release date. It undermines the customer’s confidence in you, the brand, and the product. If you’re advertising your release date, for god’s sake stick to it; if you’re bigging up the functionality, make sure you actually deliver it.
Before you release your plugin to the world, you should think about what the next stage will be. What is its scope? What does it set out to achieve? Take a step back from it, and ask whether you are trying to achieve too many things in one piece of software – if your plugin has wide-ranging functionality, perhaps a staggered release, or multi-tier product could be a better business model, enabling you to release in phases, build multiple, more focused products, over a longer period of time, and so maximise your sales, while giving you the time to build a really high quality service offering.
A good example of this is the ‘lite’ and ‘pro’ model mentioned earlier. Develop your core idea and functionality, and get it out there. Then spend some time thinking about how to enhance this functionality in various helpful ways – this gives your customers time to become familiar with, and hopefully impressed by the lite plugin, and understand its usefulness. You then have a group of core users who you can market your ‘pro’ version to, who should be primed and ready to buy, after being thoroughly impressed by your useful and considered lite offering.
Be careful though not to go overboard with the pro version – unnecessary functionality will just confuse and overwhelm users. If the enhanced functionality is highly specific – which is great, it will thus be highly useful to a specific group of people – then perhaps an ‘add-on’ model is more suitable than a two-level one. Here you can give away the core plugin, and spend time creating multiple more niche products to supplement it, with a pricing model to match.
Of course, once you have a plugin, it needs a name. I wouldn’t like to guess how many plugins there are in the world, and they are all trying to catch the eye of potential users. However, before you get carried away with creative name brainstorming, remember, plugins are a functional product – they are purchased for their problem-solving capacity, so the best strategy, in our view, is to name the plugin, and its add-ons, in a way that showcases its functionality and leaves the user in no doubt of what it does, and who is providing it, and try to keep a vein of consistency across all versions if you are using a lite/pro/add-on model.
I hope that in this post I have answered some questions you may have, if you have anything you would like to add feel free to leave a comment.