When non-profits become frustrated with their current technology (or they realize it has become out-of-date), they decide to overhaul it. This is a very complicated task and rarely done less than every five years, so the team that did the last one is generally not around to shepherd the project again. All of the lessons learned are gone, leaving the new team with the same problems but without the benefit of experience.

Buy versus build is a complicated decision. The smart way to approach this problem is through a series of questions. What do we need the system to do? What are the cost and time limitations? Does the existing system need to be scrapped entirely, including institutional knowledge with the staff of using the existing system? Is what we need now what we will need in a few years? How do we avoid the huge expense of another overhaul in another seven to ten years?

Point Counter-Point: Buy versus Build

If money is no object - or an organization has a complex, unique IT environment - building software can be an attractive choice. Built specifically for you, the system will do everything you need it to, while an off-the-shelf product may need to be tweaked or modified to accomplish the same. However, there are risks. Development delays and cost overruns are common to custom development projects.

Planning for a custom solution can be more complicated than buying a product. E-commerce might not be on the technology roadmap for your organization for another three to four years, although it needs to be planned for in the initial project architecture. Otherwise, you might find that the e-commerce solution that best suits your needs won't integrate nicely with your current systems. Here, you'd be faced with another expensive decision. An existing product can grow with your organization as the vendor adds features and will most likely have a ready-made ecosystem of partners that are actively updating and integrating with each other. This lessens the risk of non-compatibility when you are ready to add e-commerce (or any other platform expansion).

As the custom solution begins to age, support, legacy code and new technology integration become factors. Being 'custom' means that there aren't going to be a variety of support teams who are already familiar with your system and who can offer competitive rates for the work. There also won't be updates being developed periodically to keep your, now aging, system current.

Buying software alleviates these forward-planning issues and several more. While a product-based solution might not provide 100% of the functionality that a custom solution would, the longevity, cost control and stability of the technology may be more important. For example, buying a product means there's a company who stands behind that product, actively updates code and features, and supplies support.

Take into consideration staff's use of the system now and in the future. Will everyone need to be trained because you have a custom solution - hence, THE ONLY one? Or, could there be a population of recruits who already understand the basics of how a product solution works? The latter scenario will shorten the learning curve for new staff for many years and allow them to be more productive sooner.

When Buy Actually Means Build

If you decide that buy is right for your organization, beware that many software vendors who claim to sell an off-the-shelf product actually sell a custom solution. This is termed "consultingware" and almost always leads to an incomplete solution, specifically designed to require customization services and nearly impossible to upgrade without substantial cost. Providing continued customization services is how many consultingware vendors maintain their revenue goals. If the organization either cannot afford to or chooses not to continually revisit this customized software system, the result is obsolescence of the product over time.

"True" software companies, on the other hand, try to minimize the amount of consulting service required, so they can move on and sell and install their software for the next customer. These software companies maximize their customers' initial software investments by protecting their upgrade path.

It is no wonder many organizations are confused. Most software vendors operate in a way that almost guarantees that the organization will get stuck in time with unsupported versions of software. To make matters worse, out of self-preservation, they all say they can upgrade (largely through customization of the base product). While that might be at least partially true, organizations often do not understand that the more customization is added to the base product, the larger the problem of future upgrades becomes.

Sometimes consultingware vendors say things like, "we will roll our customizations into your base product." The fact is, it takes incredible management talent to keep track of all the customizations done to a customer's base software. What's more, most customizations are extremely technically challenging to integrate with other products. For that reason alone, system implementations from software consultants often come in over budget, and take much longer than planned.

Selecting a software solution for your organization may be one of the biggest professional decisions you will ever make. A little due diligence up front will make the difference between a truly upgradeable software solution that will grow with your organization's needs, and a long-term commitment with a company that's constantly bolting on new functionality to a patchwork quilt that never quite fits your organization's expectations or budget.