Why should I pay for developed add-ons when my software should do ‘X’ anyway!?

I started this blog article in response to the comment made in the QuoteWerks software support forum here: “I know there are add-ons to correct the date, but why should we need an add-on to get basic functionality?”

For anyone who’s reading this that’s not familiar with my (and Hilltops IT / ConnectIT Software‘s) background – as well as providing licensing, consultancy, training and support for off the shelf business software solutions (such as QuoteWerks, Microsoft Dynamics CRM, Sage 50 Accounts, Sage 200 and Sage MAS) we also have a number of add-on solutions for these applications.

So… this is a very interesting subject for me! If people decline to use add-ons, then half my business is gone!!! BUT, if I can better understand what motivates or demotivates people to use add-ons, then it can help me deliver more successfully.

The issue of developed software add-ons

Abstracting this from the specifics of QuoteWerks development post, why SHOULD people pay for add-ons to be developed when they feel that their need is ‘basic’ or ‘fundamental’ within the software that they use? As someone who uses various software applications day-in, day-out, has a long history of developing software solutions from scratch and currently develops software add-on solutions, I feel quite well qualified to at least offer a first draft of thoughts on this.

Let’s look at the issue from the perspective of the main software developer, the end user and the add-on developer. I’ll then draw my conclusions and look forward to reading your thoughts and comments in due course.

From the software developer’s perspective

So let’s assume that I’m a good developer – I’ve got my enhancement log and process for people to submit requests. I’ll review that list every build, plus look at what support queries I’m getting where end users are having difficulty using particular features, listen to my sales and marketing team as to what prospective users and markets might want and I’ll have an overall strategic direction that I want to take the software.

So who gets priority when I plan my build? Well, it’s a balance…

I can’t just satisfy existing users’ one-off requests – that may push the software into being very complicated to set up with lots of very specific user requirements switchable and irrelevant to most users. I may also find myself in a situation where different user’s needs conflict – I push here, which gets pulled there and it all collapses. But I definitely can’t ignore this group either – these will be the people I go to for testimonials, case studies and I want them saying good things about my support / responsiveness to other prospective companies that may adopt my software.

I should be looking at support queries where users are having difficulty. This may suggest that the software’s overly complex or not intuitive enough and could be a barrier for people getting the most from the software.

I also need to listen to my sales and marketing team and the overall strategic direction for the software. If I don’t, then like any business that doesn’t look forward, I could end up slipping backwards and certainly risk having competitors get in front of me.

From the end user’s perspective

Any software developer worth working with is going to have some form of development enhancement request process, so I can submit my requirements here. But I might have to wait. I might have to wait a long time. If the software developer isn’t being asked for the feature by a good percentage of other users (or even more persuasive may be the prospective users) then there may be minimal motivation to add the necessary code.

Maybe there are workarounds to meet my requirement – either automated or manual – but these may be more or less practical to implement. Maybe I could develop the solution myself, but this is probably not going to be cost-effective.

So, I am left with looking at add-ons. And, actually, I might be quite impressed with what I see. Not only will the add-on answer the problem that I have, but it may well also open up other avenues for my usage of the main software. Add-ons are typically priced relative to the product that they enhance and the feature benefit that they deliver, so, actually, I might be in a much better position.

From the add-on developer’s perspective

Well, I love gaps in software. Particularly where there’s more than one user wanting the gap filled, and even moreso when those users are in different industries where I know that the main software is very popular. This all suggests good opportunities for me and my products / services.

To sympathise with the main software developer who may have gone down a route in building a particular piece of functionality that may be tricky to devolve, as an add-on developer I don’t have that legacy to worry about. I’ll also package my solutions in what are relatively smaller packages with options, so reducing the conflict between pieces of functionality between user A versus user B’s requirements.

Some main software developers may encourage me to develop my add-ons by providing detailed notes on their API functions, sample code snippets and even support forums. Others may be less encouraging and make me pay for the API information, having convoluted interfaces to the software program and database… you know who you are!!!

I can take a fresh look at the main software, look at it from a different perspective. Assuming that I’ve got a rounded API (application programming interface – the way that I ‘talk’ to the main software), then I can focus on delivering the requirement from a whole different angle.

My Conclusion on Add-On Software Developments

Rightly or wrongly, you just know that I’m going to come down in favour of add-ons. (They are 50% of my business after all!!!) For me, they offer a way to provide creative and innovative solutions for very specific user / business requirements without having to develop a solution from scratch.

Back in the day, I’d be hacking out solutions for problems from the ground up – a flat file, non-ODBC database format and an un-customisable front end. You’d need to have the source code to make any form of change to the software and as for a.n.other app reading the database and interoperability – forget it.

Moving on to VB and VBScript apps based on Word, Excel or Access – we had an open database, could potentially build your own interfaces and reports, but we were still building apps from the ground up. There was just so much duplication in what we were doing for client A versus client B. The solutions were (relatively) cost-effective because we could often take 80% of solution A to build solution B, but we still fundamentally had two code-bases to build and maintain ongoing.

We’re now in an era where off-the-shelf software is considerably more open to change – incredibly flexible with the tools available within the application itself, plus the wonderful API that the add-on developer can use to sprinkle that last 20% of magic. I’m not duplicating the 80% between the solution for client A and B any more – client A and client B are using the same application, they just aren’t getting everything that they want from it. I can now concentrate on making my add-on 20% as flexible as possible (within reason) to satisfy both client A and client B’s extra requirements.

Then there’s the web, but that’s a whole different blog article… or is it…?

If you made it this far, then thanks for reading and I look forward to reading your thoughts and comments in due course.