Acquiring Edit Lock
is currently editing this page.

How to make a decision that works

To buy or to build? That's how we often frame the question about whether to invest in off-the-shelf software or to create a custom application from scratch.

IT managers often feel strongly about this issue. Some will tell you to build every time, while others say to buy without question. Many fall between those two extremes.

To resolve the issue for your organization, consider the pros and cons of buying and building — then look for ways to expand the options and make a decision that works.

Pros and cons of buying

Buying software has many appeals. You can budget for the purchase. You know the software has been tested. It comes with documentation and is often supported with warranties and free training from the vendor. When you buy, you don't have to take your own IT staff away from their current duties to develop software.

Yet there some potential drawbacks to buying software. For example:

  • Hidden expenses. The total cost of owning software goes beyond purchase price. Remember to add the costs of installing software and paying for future updates or additional site licenses. If a vendor can't resolve a particular issue, you could end up buying help from a consultant.
  • Lack of fit. It's unlikely that any software — even systems built specifically for nonprofits — will provide all the features you want. You might decide to install add-ons or customize the application. But both of those decisions take time, money and expertise.
  • Outdated products. If a vendor stops updating or supporting software, you may be stuck with an obsolete product.

Pros and cons of building

Given the downsides of buying, some IT managers opt to build an application from scratch. In return, they get desired features, compatibility with other applications and the option to further customize the software as the organization grows. Because the application is developed in-house, support and maintenance is built in as well.

Even so, building comes with its own set of potential issues. For example:

  • Resource demands. If you develop software in-house, then your staff is responsible for building, testing, debugging, updating, supporting and training. This might call for new hires. If you contract with an outside developer, then you're subject to their production schedule. And, your contractor might want to retain ownership of the source code.
  • Time and cost overruns. It's notoriously challenging to schedule and budget for software development. Lean and agile methodologies can help, but not all developers use them. If you need new software to fix a key process immediately, customizing may not be feasible.
  • Loss of expertise. Imagine your organization one or two years from today. Will there be a turnover in your IT staff during that time? If so, who'll have the expertise to support your custom-built software?
  • Competition from off-the-shelf applications. More vendors are developing sophisticated software specifically for nonprofits, and many of these products can be customized more easily than past versions.
  • Opportunity costs and loss of focus. Is building software the best thing for your organization to be doing right now? Technology is a means to an end — one of many paths to your vision. Devoting resources to software development may mean taking them away from other mission-critical projects.

More options — and a bigger question

Given the above considerations, the choice is seldom simply to buy or build. Use creative thinking to expand your possibilities. For example, you might:

  • Build some applications and buy others
  • Download an open source application and customize it
  • Use cloud-based software as a service that you neither buy nor build
  • Hunt for unused features embedded in your existing software — and train your staff to use them
  • Adopt workarounds to get past shortcomings in your current software
  • Adopt more efficient work processes rather than look to software for a solution

Since both buying and building software require IT talent, time and money, the bigger question is this: Do you currently have the resources to do either?

Given all the variables, you might weigh the risks and benefits of simply doing nothing about new software for now. In some cases, it may be wiser to revisit your buy or build options in future — when you have more capacity and the next generation of software is ready for testing.



MissionBox editorial content is offered as guidance only, and is not meant, nor should it be construed as, a replacement for certified, professional expertise.



Blackbaud: Selecting software for your nonprofit (2013)

Code Project: Software build vs. buy: What's best for you? by Mark H. Dynms (2012)

Computerworld: To build or buy software: Ask these 5 questions first by Andrew Montalenti (2016)

Dice: Build vs. buy: The 7 most important questions to ask by Stephen Lahanas (2013)



Writer and editor fascinated by knowledge management, behavior change and technology for nonprofits