Make or Buy: Should You Let Someone Else Build Your Nonprofit Mobile App?

Six years ago, I wrote an article on why nonprofits aren’t going mobile while mobility was exploding in the startup sector. Over the last six years, I’ve had the opportunity to build a number of mobile apps in the nonprofit sector and seen the innovation cycle at work in the nonprofit mobile app space (including all of the zombie apps). We’ve now reached a phase where smartphones have reached saturation in developed countries and are highly accessible in most developing countries.

The most popular mobile apps reach billions of people daily, making a select number of companies (Facebook, Google, etc.) billions annually. Past those with the most brand recognition, there are many unknown mobile apps with 1M+ users. There is a lot of money in mobile apps.

At the same time, the number of nonprofits has increased by ~100K over the last six years and fundraising has not grown at the same rate. We often ask folks, “What are the hardest technology projects your team is working on?” and, consistently, we hear nonprofits are struggling with data and mobile apps. We’ll save data for another article, but mobile is a tough space for nonprofits. Everyone wants a great mobile experience — payments, events, CRM, program delivery — but it’s difficult to create an amazing experience. After six years of building mobile apps, my recommendation: Let someone else do it.

I’ve learned a few things about how to build a mobile app. Most mobile apps are simple in design, but difficult in delivery. A few barriers include:

• Users are forced to download apps.
• Apps require either two separate frameworks (i.e. iOS and Android) or a well thought out single framework (i.e. ReactNative or Flutter).
• There are hundreds of Android devices, so testing is difficult and expensive.
• The Apple store is a challenge to navigate.
• Smartphone users expect beautiful, fast design in all environments.
• Unlike websites, there are fewer low-code options available (and they’re not as good).
• Anything that requires significant user input rarely works.
• Apps work best when they have clear goals and tight focus on meeting those goals.

All of these make mobile more costly and less straightforward than web development. All of this is to say: Building mobile apps is difficult. Which is why you should either find an existing app that does what you need or try to find a web-based way to do what you need.

However, if you are convinced you need a mobile app, then there are a few tests you can run through to make sure before you decide to start. These are:

Credit: Jared Sheehan

Do You Have a Really Great Mobile Use Case?

Most new technology ideas are better created and tested using a mobile responsive website rather than building a mobile app. Users need a vested interest to download an app. For instance, I want to play League of Legends and am willing to do whatever I can to spend 1,000 hours in front of it. However, if you want me to download another payment app, no way!

Your mobile use case must rely on native smartphone features. Does it involve geographic components? Video or photos? Gyroscopes? Can the user do the use case during a boring lecture or right before an airplane takes off? If so, you’ve found a great mobile use case. Simplicity is better with mobile. Start with a single use case and expand from there.

For instance, the In Flight app was a great mobile use case because the users were meeting with dozens of corporate partners daily. They were taking handwritten notes and transferring them to their desktop apps. So we used native phone features to take campaign photos, check in and write notes.

Do You Have the Right Audience?

People weigh their technology decisions based on incentives and deterrents. If you pay them $5, they’ll download an app. If you don’t let them do something they want to do without downloading an app (e.g. conference details), they’ll download it. With mobile, your carrot or stick needs to be larger than a website. Are you giving the users free content they care about? Do they have to download your mobile app to volunteer? These will drive adoption of your mobile app.

Audience adoption also needs to be compared to market size. If you’re St. Jude Children's Research Hospital, then you have a larger potential market size than if you’re smaller. If you build a mobile app to support internal processes compared to one that will engage people on your mailing list, the market size is different. However, it is very likely your audience captivity and size are inversely correlated to each other.

For instance, we built an app to help individuals overdosing on opioids to reduce the likelihood of overdosing (which I won’t link here for privacy purposes). Our alpha version of the app had hundreds of people asking for it before we could comfortably give it to them. On the other hand, we’ve built internal employee-focused apps that saved people hours of work daily that got lukewarm results because it required them to change their process.

Has Someone Else Already Built Your Idea?

One of the common things I’ve heard about from prospective mobile creators is, “I want to build [insert unicorn mobile app] but for nonprofits.” It’s almost always a bad idea. If you’re on a tight or moderate budget and want to build your own version of a well-known app, know that someone has probably already done it or will do it. Your idea needs to fit your specific organizational needs and not a copy of another organization’s core identity. Unless you’re in China, then ignore this section.

If someone hasn’t already done it and it’s a good idea, the well-known organization is likely working on the idea from their users telling them to do it (i.e. user research). As an example, our previous company tried building Instagram for nonprofits except that Instagram is great for nonprofits. Needless to say, it failed.

Do You Have the Right Team to Build It?

Mobile development is very different from web development. Mobile apps need to feel simple to users, but should pack a significant amount of research, user experience design and testing that is different from web development. Good mobile development requires people who are mobile native and have experienced the pain themselves. Web development, in contrast, can be done from someone sitting behind a computer (because the developer has the same experience as the user).

One thing most web-only developers do not realize is that mobile user research really only works if the product and design team go with the users along their daily routines/routes. For our products, we often do dozens if not hundreds of these “ride alongs” to ensure what we’re building works on-the-go, from the car and when you have limited cell service. As well, testing mobile apps is very different from testing websites. Mobile apps require dozens of test devices, while there are web services to allow for testing online.

As an example, when we built our NeonMoves mobile app, we originally built it to support both corporate partner check-ins as well as donors. However, the donor space was new to us. We met with major gift officers and other fundraisers to understand their pain points and ensure the app works for them. Luckily, we have a great partner in Neon One that have supported us throughout the process.

Is Mobile a Core Competency for Your Team?

Building a mobile app from the ground up requires a significantly different skill set from providing a strong web presence or developing a strong IT backbone from your organization. It requires a significant up-front investment, serious user research, product design and management skills, championing throughout the organization and ongoing upkeep as the list of supported devices change every single year.

While these are skill sets that can be grown and learned, they often require a significant investment in an area that does not directly help a nonprofit deliver on its core mission.

Are You Not to Be Deterred?

If you still want to build it after those questions, then great! You probably do have a unique idea that could turn into an amazing mobile app. If I haven’t deterred you, then you should do it.

My final point of caution is that mobile projects seem very small in the beginning. Getting to an alpha mobile app can be a small budget, but mobile’s real challenge is keeping the budget under control as it grows. Design, development and testing needs often are larger than you think (by a magnitude of two to three times).

We have really enjoyed building a number of mobile apps with our nonprofit partners over the last six years. Our team has grown. Our partners have increased. And mobile app development continues to be fun. If you’re about to embark down the path, I wish you luck. Always feel free to reach out if you have questions.