FUNDRAISING SOFTWARE
The Road to Perdition: Building Your Own Database
Originally published under the title “Why Building Your Own Database Should Be Your Last Resort”
BY: Robert Weiner, Robert L. Weiner Consulting (robert@rlweiner.com) and the Nonprofit
Technology Enterprise Network (www.nten.org).  Used with the permission of the author.

Many not-for profit organizations want to upgrade their donor tracking capabilities because they have outgrown using spreadsheets to track gifts, donors, and contacts.  They want a sophisticated database that will help them to better identify, cultivate, and communicate with their best donors.  

Many of these organizations try to meet their
goals by building their own donor databases.

There are certainly instances when a custom database is the best or only solution.  But those are few and far between.  Many not-for-profits that I talk to are not usually building their own database because they have unique requirements.  They probably just have a copy of FileMaker or Access and maybe a volunteer who knows how to use it. 

There are several reasons why they should
not try to build their own database ...

1.  Risk: Building a database is a risky proposition.  I have seen countless custom database projects that failed to meet the organization’s needs.  There have been a variety of causes: requirements weren’t clearly understood or articulated by the organization or they were changing constantly; the programmer got distracted by other projects or left the organization; bugs were never fixed; reports and documentation never got written. Whatever the reason, these projects turned out to be frustrating, costly, time-consuming examples of good intentions yielding bad results.  Yes, I have seen successful custom donor databases.  Many of today’s commercial databases started that way.  But I have seen many more failures than successes.

2. Focus: Building a donor database requires significant input from the people who will use it.  They need to describe in detail the minutia of daily operations as well as management’s reporting needs.  I ask you:  is turning fundraisers into database designers really the best use of their time?

3.  Support and Maintenance: Who will you call when your homegrown system has problems?  What if the person who designed the database isn’t available?  What if you need new functionality that’s beyond the technical skills of the original programmer?  Building a database is an iterative process:  you will want to make changes over time.  Without ongoing support and maintenance … bugs won’t be fixed, questions won’t be answered, changing needs won’t be addressed.

4.  Training:  Who will train staff to use the system?  Software training is an art and not everyone is good at it. But let’s say the person who built the system provides great training.  Will she be available for years to come as you add new staff?  And, just as important, will you have the necessary training and reference manuals?  How will you keep database training from being like a game of “telephone,” where the tenth person trained hears something totally different from the first person (and the garbage in your database reflects it)?

5.  User Community:  With commercial database applications, a host of programmers and user-clients are providing input to help improve the software.  There are user groups (both physical and virtual) where you can learn how other organizations are using the software.  There are other clients of whom you can ask questions when problems arise.  In building your own database, there’s seldom anyone you can turn to for advice or help.

6.  Documentation:  There are three types of database documentation. The first is technical:  it tells other programmers why the database was designed the way it was.  The second helps train staff members on how to use the database (“click this button to go to that screen”).  The third describes your organization’s procedures, so the right data goes in the right place.  When it comes to homegrown databases, all three types of documentation are as rare as Yeti sightings.

7.  Cost: Price is the bottom line.  You can get bids for a commercial system.  How do you get a firm price and feature list for a custom system?  You must also consider the cost of staff time in designing and testing the system.   Keep in mind that every change to the database will cost money.  Will you be able to pay for upgrades to fix problems and keep up with evolving technologies?   While a custom database may seem like a bargain up front, in the long run it may cost a lot more than a commercial database.

The bottom line:  There are certainly times when a custom database is the least expensive, most effective, or even the only solution.  But I urge you to consider the true costs, benefits, and risks of building your own database before going down the path that some have described as the Road to Perdition.