Does My Nonprofit Really Need an App?

Lou
Kotsinis

Building an app is a significant investment in time, money and resources. Sometimes it’s worth the effort, helping you to elevate your brand and engage more consistently with your audiences. In other cases, it can be an unnecessary expense that diverts resources from more effective digital strategies.

If you’re a nonprofit that’s considering an app, there are 3 questions you should be asking that will help you decide how to proceed:

1. Are the tasks you want the app to perform things that your users need to access quickly and on a repeated basis?
2. Are these tasks things that your website can’t already handle well?
3. Based on the time and money you’ll be spending, do you see a clear return on investment? This could mean happier users, greater brand affinity, increased donations, or other metrics that define value for your organization.

If you can answer “yes” to all of these questions, then investing in an app may be a smart move. If not, you should consider sticking with your website to achieve these tasks, and invest there to improve your users’ experience.

Let’s look at each of these questions through the lens of two hypothetical nonprofits:

Both Causes A and B are of the same size and geographic footprint; they were founded at roughly the same time and are established, mature organizations with similar assets and operating budgets.

Do They Need an App? Cause A vs. Cause B

Applying the 3-question framework I introduced above, here’s how each cause can assess whether to build an app, or guide users to their website.

1. Are the tasks you want this app to perform things that your users need to access quickly and on a repeated basis?

This question gets at the heart of why anyone typically needs an app – convenience – something that depending on the function, a website may not provide effectively.

Banking is a great example. To check your account balance on your phone using a bank’s website, you have to:

1. Open a web browser
2. Type in the name of your bank
3. Locate the bank in the search results and click
4. Find the login on the site page
5. Login

But with an app, you:

1. Click on the bank’s app icon
2. Login

Checking your bank balance is something most people want to do daily, and they don’t necessarily want to wait for that information. An app delivers this function flawlessly.

So let’s apply this logic against our two nonprofits:

Recall that Cause A is considering an app to keep audiences informed regarding “services, upcoming events, and educational resources specific to their family member’s needs.”

The first question I would ask this ED is around frequency. How often do her users – parents and families – need to find out about events?

Unless the “events” in question were both critical to the member’s health, and/or their content changes continually, users probably wouldn’t need constant access to an event schedule.

And regarding services and educational resources, unless these were items that a parent or caregiver needed regularly – say on a daily basis – this is content that users could access at their leisure via the cause’s website.

Verdict: Website

Cause B’s need for task repetition and speed is more defined. They want their users to have “ready access to health records and forms.” It’s helpful to think about our own experience here. When do most people typically need to access health records? In a medical professional’s office, i.e. – when they’re away from their computer.

So this task lends itself to a mobile device. And if you’re going to be on a mobile device accessing or completing a form, you’ll want both speed and convenience (see our example of the bank app above).

Verdict: App

2. Are the tasks things that your website can’t already handle well?

Ever notice that there aren’t many “apps” on your laptop? That’s because the web on laptops and desktop computers works flawlessly. Mobile web? Not so much. And since mobile is where our need for convenience and speed come in, here is where you should be directing your analysis.

Cause A wants a “ready resource for learning and planning.” Again, this includes easy access to events, services and educational content. By definition, a website is the tool that can house and provide this information. A well-designed, well-planned web experience will allow Cause A’s constituents to immerse themselves in the organization’s mission and take their time to learn and plan around services available to them.

That’s on a laptop. What about on a user’s mobile device? These days, many of us do our reading on phones, and barring a poor user mobile website experience – which Cause A can handle through a site redesign or enhancement – there’s no obvious need here to build out a separate experience to serve the same function.

An exception here would be if Cause A could prove that most of its users are in a region with poor internet connectivity to the web – whereby an app could provide offline functionality and local storage so that users could access information without a web connection. Barring that? Web.

Verdict: Website

Recall that Cause B wants its users to have:

1. Access to health records and forms

2.The ability to record and refer back to treatment videos

How well can the web handle these tasks?

On the desktop/laptop web, Cause B is in good shape – forms and records are easily usable and accessible, and as far as video is concerned, videos of even massive size can be uploaded and stored on a third-party video app, which is then integrated to the Cause B site.

But on mobile, it’s a different story. If you’ve ever tried filling out a form on a mobile website, you know that it’s usually a clunky experience. This is why some health care providers offer a mobile app, which provides a smoother experience. So for Cause B, where users need regular access to forms and documents, an app would be a wise choice.

Moreover, the need for video also supports the building of an app, which can directly access mobile device features, making the capturing and storage of video more efficient than a traditional website. 

Verdict: App

3. Do you see a clear return on investment?

An app is an expensive proposition. A native app – i.e. an app designed for the device itself, and which is placed in and accessed via an “app store,” can cost hundreds of thousands of dollars for each device platform (e.g. Apple’s iOS and Google’s Android), exclusive of ongoing maintenance and support. 

A progressive web app, which combines elements of native app development and traditional mobile web functionality, can be a cheaper option, but will still run in the tens of thousands of dollars. 

To this end, it’s critical that nonprofits think through the ROI of their app investment. Will the app provide your users obvious and specific value, that your website won’t itself deliver? And if so, can you measure that value relative to what you’ll be spending on the app? 

“Value” and ROI are different for every organization, but here are some benefits to consider:

Financial:

• Potential for generating donations or revenue
• Cost savings from operational efficiencies

Strategic:

• Innovative positioning in the nonprofit sector
• Growth of brand affinity among users and the public
• Potential partnerships enabled by the technology
• Quality of user experience for beneficiaries
• Ability to reach underserved populations
• Measurable impact on mission-related outcomes

Operational:

• Integration capabilities with existing systems
• Scalability as user base grows
• Security and data privacy standards
• Efficiency gains in service delivery

Let’s consider our two causes’ decision-making process against this ROI list. 

There’s no evidence that by investing tens (or hundreds) of thousands of dollars into an app that basically provides events and content that Cause A will be better positioned to generate additional revenue.

And since Cause A’s website can readily handle the functions they want to deliver, there isn’t an operational benefit in investing in an app, either. 

Strategically, an app could be something Cause A can promote as a value-added service for their audiences and might be seen as an “innovation.” To these ends it may slightly improve brand affinity among certain users, but since there’s no truly unique value to the app functionality, any benefits here would quickly fade. 

In short, if Cause A was our client, we’d guide them away from an app, and encourage them to invest more into their website to achieve their goals. 

Verdict: Website 

To understand the potential ROI of an app for Cause B, let’s consider again the benefits its audience will derive from an app:

Utility – recall that Cause B’s app will serve a key constituent function – easy and ready access to both health forms and records – a high-value function that will make users happy

Convenience – the app will make the taking and storing of videos and access to key operational functions easier  

Reassurance – Quick and secure access to critical information is yet another benefit an app can bring

Based on these traits alone, an app meets many of the benefits listed above. 

Since our example is hypothetical, we can’t know what, if any, cost savings will derive from producing the app. And, I doubt that this tool could be harnessed for fundraising or sales – but then again, it was never meant for that purpose. 

Verdict: App 

***********************************************

So, Who Gets the App?

Obviously, Cause B “gets” the app. I’ve made the “Cause A vs. Cause B” scenario purposefully simple to help illustrate an initial framework for building an app; in reality, your organization’s functional and strategic needs will be more complex than the examples we’ve used above, but you can use this framework to guide your choice.  

Hopefully, what I’ve laid out here equips you to better respond to that board member who at the next meeting says, “maybe we need app?” To which you can now respond, “maybe we do – and maybe we don’t. Here’s what I think….”

Good luck, and If you want to discuss further, I’m only an email away.

TAGS: