One of my "standard" rules is, generally speaking, associations should not be in the business of developing their own software. I explain all my reasoning about that position here.
But like pretty much every rule in life, there are certain exceptions. (Note here that "develop software" includes hiring a third party to build it; it doesn't mean that only your staff can do it.) So here are some reasons why your association might need to develop software:
- There really isn't software to do what you need to do. I've found that probably 80% of the time, there is already software available to do what an association is trying to, either directly designed for that purpose, or close enough to allow adaptation of existing software. But there are rare occasions where a process the association is trying to automate really doesn't have any off-the-shelf options available. And so in those cases, if software can be developed in a time- and cost-effective manner, it may merit developing your own.
- The software that is available to address the need is cost-prohibitive. This is the scenario that I see more often. The association needs a particular set of functionality (e.g., awards applications judging and processing) but the alternatives available are all too expensive. But automation is greatly desired, so it may make sense for the association to explore building their own.
Something to keep in mind in every case, when exploring software (buying or building) is that the answer may be: "We don't need software to do this job." Sometimes the process we're trying to automate is best done manually. (Here are some examples.)
Again, most rules have exceptions. In the vast majority of cases, associations should not be building their own software. But there may be cases where they should. Most often you can find software to suit your purpose, or you can manage the data manually. Use your best judgment.