"We need an app" is one of the most common things I hear from organisations that serve others, and one of the least often correct. It is not that apps are bad. It is that an app is the most expensive, most fragile and most maintenance-hungry way to solve most of the problems people bring to it. In many cases, a well-built web page, a form, a spreadsheet or a WhatsApp group does the job better, sooner, and for years without attention.
I build applications when they are the right answer. This is how I decide, and how you can too.
An app is not a goal. It is a cost you accept when nothing simpler will do the job.
Five questions to answer first
1. What exactly will someone do with it, and how often?
Write the answer as a sentence: "A volunteer will open it every Saturday to record which families received rations." If you cannot write that sentence, you do not need an app yet. You need to understand the task. If the answer is "read about us" or "see our events" or "donate", you need a website, not an app. Nobody installs an app to read about an organisation.
2. Who will use it, and will they install it?
Be honest about your users. Elderly beneficiaries on shared phones with little storage will not install an app. Occasional donors will not install an app. Volunteers who come twice a year will not remember the password. Apps work for people who use them frequently and have a reason to keep them. That is usually staff and regular volunteers, and rarely the public.
3. Does it need anything only a phone app can do?
There is a short list of things that genuinely require a native app: working fully offline for long periods, running in the background, using the camera or GPS heavily in the field, sending push notifications, or integrating with device hardware. If your need is on that list, an app may be right. If it is "fill a form", "look up a record", "see a schedule" or "make a payment", a modern web application does all of that on any phone with no installation, no app store, and one codebase to maintain.
4. Who will maintain it, and with what?
This is the question that kills most nonprofit apps, usually eighteen months after launch. Operating systems update. App store rules change. Certificates expire. The developer who built it moves on. An app that is not maintained gets removed from the store or stops working, and the data inside becomes hard to reach. Before building, name the person responsible for maintenance and the source of funds for it. If you cannot, build something that needs less.
5. What happens to the data?
Apps collect information, often about vulnerable people. Where is it stored? Who can see it? What happens if a phone is lost? What happens if the organisation closes? These need answers before a line of code is written. Simpler tools often have simpler, safer answers.
What usually works better
- A good website. For anything the public needs to know or do occasionally. Findable, installable to the home screen if wanted, and one thing to maintain.
- A web application. For staff and volunteer tasks: records, attendance, inventory, scheduling, case notes. Works on any device, updates instantly for everyone, no store, no installation.
- Forms and sheets. For collecting information a few times a month, a well-designed form feeding a spreadsheet is often all that is needed, and a coordinator can change it without a developer.
- Messaging you already use. WhatsApp and similar tools are already on every phone. A broadcast list or a group with clear rules beats a notifications feature nobody enables.
- Existing tools, arranged for you. Many needs, such as donor records, volunteer rosters, event sign-ups and simple case management, are met by tools that already exist. Setting one up and connecting it to your website is a fraction of the cost of building your own.
When an app is genuinely right
Sometimes it is. Field workers collecting data in areas with no connectivity for days. Community health volunteers who need reminders and protocols in their pocket. A tool that many people use every day and that must be fast, offline and reliable. In these cases, a native or offline-first app is the correct answer, and it should be built properly: with a maintenance plan, a data plan, and an exit plan.
Even then, start smaller than you think. Build the one core task. Put it in the hands of ten real users. Learn. Then decide what to add. Most of the features on the original wish list will quietly disappear.
A decision list
- Write the one-sentence task. Who does what, how often.
- Name the users. Would they really install and return to an app?
- Check the need against the "only an app can do this" list.
- Name the person and the funds for maintenance in year two and three.
- Write down where the data lives and who can see it.
- List the simpler alternatives and say, honestly, why each one would not work.
If you get through that list and an app is still the answer, you now have the brief that makes it succeed. If you did not, you have saved a year and a good deal of money, and you know what to build instead.