What could drive your nonprofit organization to consider custom software? Maybe you need a new database application to manage your clients and services. Maybe you’ve got a great idea for a mobile app to work wonders for your constituents. You’ve searched, but the software you need just isn’t out there. How can you contract with a developer to build that software for you, while staying on-task, on-time and within budget?
It can be done! Lots of nonprofits have great experiences wtih custom-built software. A good custom product can make a world of difference for programs and administration. I’ve been building database application software for nonprofits for 25 years, and I’ve come to value a handful of principles that help put development projects on the right track. Try them out for yourself if you’re considering custom-built software for your nonprofit.
- Be very clear about what the software needs to do. Write up the “business tasks” that must be accomplished; by whom; and in what situations. Classify the users of the software and how their interactions differ. Define the reports that you’ll want to generate. Try to avoid anything “computery” in this first description; ideally, you’ll describe tasks that could be accomplished by any system, even paper-and-pencil. Put in as much detail as necessary to describe what really matters. This write-up will be thoroughly revised by your developer—but it makes a great starting point.
- See if your dream software already exists. Are you sure your needs are so unique that nobody’s ever solved them? There might already be a software package that provides 80-90% of what you need. You can save a lot of time and money with some good research. Ask everyone, especially colleagues in your field, for leads and suggestions. Software development can be expensive and labor-intensive. Skip it if you can.
- Don’t get hung up in the technology. If you’re getting stuck in the minutiae of SQL, HTML5 and the latest Javascript framework, you’re probably in way too deep. Let your developer worry about the bits and bytes. Your focus will be on the tasks, not on the tech.
- Find the right developer for you. Be sure your developer has a great and extensive track record, ideally with projects much like yours. Check references fully. (I’m astonished by how rarely clients ask for my references. How do they know I’m any good?) You’re going to be working closely with your developer, so be sure that you like and understand her, and that she shows a good understanding of your business and your software needs.
- Pay by the development task, not by the hour. You’ll probably have to break your project into sections. First your developer needs to understand your project; next he’ll write software specifications (see tip 7. below); after that she’ll build the software itself, install it, perhaps convert existing data, train staff, and finally deliver documentation. You can’t really expect your developer to know how much the latter stages will cost before the early stages are complete. That’s okay. Just be sure that you have a firm (written!) agreement of budget, deadline and scope of work for the current phase, whatever it is.
- Be prepared to work. An experienced developer starts by asking questions—lots of questions. To build great software, he’ll have to understand your program in great detail. Pick a single primary, high-level contact person (possibly you?) who can answer your developer’s questions, make decisions, and collect feedback from the rest of the organization. Your developer may want to talk to different staff members. But when she needs answers and decisions, the main contact person must deliver without undue delay.
- Never build software without written specs! Your developer should draft a Specifications Document, which will be the blueprint for your software application. It describes exactly what the software will do, in advance, so you don’t get any nasty surprises when you actually take delivery. The specs should take you through the software, screen by screen and widget by widget, clearly and without ambiguities. Don’t let your developer write one line of code until you’ve read, understood, revised, and approved the specs.
- Have a plan for software support and maintenance. What happens if the software malfunctions? What happens if you want new features, a year from now? What are maintenance tasks (such as data backup, updating system parameters, security and bug fixes) and who will carry them out? Will you have the “source code” needed to make changes? Work with your developer to decide such details in advance. And be sure your software is developed using standard, well-supported technologies, so that you’re not locked in to strange, proprietary or obsolete tools and languages.
- All your questions are smart questions. You’re not a software developer; you’re a manager. You don’t need to know the inner workings of AJAX calls or distributed servers. But by the same token, you’re a smart person. If you have a question, it’s a good question and it needs to be addressed. Never be afraid to ask something elementary. Don’t give up until you get an answer that you fully undertand.
Let’s face it: getting custom software can be a challenge. It takes time, care and money. It can be especially trying if you’re easily daunted by the cryptic diagrams and geeky acronyms of software technology.
The good news is that contract software development can be a great experience. We’ve worked with many dozens of nonprofits that are delighted with their developers and can’t imagine doing business without their custom software applications. I hope the simple, common-sense suggestions above help your organization join them. Good luck!
