A program officer approves a grant. Inside it, a line item: mobile application, $85,000. Eighteen months later the final report lands. The app was delivered on time and under budget. Adoption in the field was 11%.
Nobody did anything wrong, exactly. The developer built what was specified. The implementing partner deployed it. The problem was that the app needed a data connection to open, and the community health workers it was built for spend most of their working day in places with no signal.
This happens constantly, and it is almost always preventable. What follows is a practical guide for foundations, INGOs and grantmakers financing technology components in field programmes — what actually goes wrong, what to ask before you sign, and what it costs to do properly.
We write this from experience. In 2026 our team delivered Safe Catch, an offline-first safety app for small-scale fishermen on the coast of Balochistan, Pakistan, for a locally-led NGO under a UK foundation grant. It runs on entry-level Android phones with no internet connection at all. Some of what follows is what we got right. Some of it is what we had to fix.
The assumption that breaks the most grant-funded apps
Almost every commercially available app assumes a persistent connection. The screens you see are drawn from a server. Take the connection away and you get a spinner.
That assumption is invisible in a proposal. It does not appear in a wireframe. It does not show up in a demo, because the demo happens in a conference room with WiFi. It surfaces for the first time when a field officer is standing in a village holding a phone that will not load.
For programmes in rural sub-Saharan Africa, South and Southeast Asia, remote Latin America, small island states, or frankly large parts of the rural United States, this single assumption determines whether the investment produces anything at all.
There is a name for the alternative — offline-first architecture — and it is a genuinely different way of building software, not a setting you enable at the end.
Offline-first, in plain terms
In a conventional app, the phone asks the server for data every time the user does something. The server is the source of truth. The phone is a window onto it.
In an offline-first app, the phone holds its own complete copy of everything it needs. The user works against local storage, always, whether connected or not. When a connection happens to appear — thirty seconds of signal at a district office, a hotspot at a partner clinic, the walk past a cell tower — the app quietly synchronises in the background. The user does not initiate it and often does not notice it.
The practical consequences for a programme:
- Field workers never wait, and never lose work
- Data captured offline is not lost when the app closes
- Content updates reach devices without anyone travelling to collect them
- The programme keeps functioning through outages, shutdowns and dead zones
The engineering cost is real. Building this way typically adds meaningful effort compared with a conventional connected app, because conflict resolution, sync logic and local storage all have to be designed rather than inherited from a framework. That cost should be in the budget from the first draft, not discovered in month four.
Six questions to ask before you approve a technology line item
None of these require a technical background. All of them are answerable in one meeting.
1. “Show me the app working in airplane mode.”
Not a description. A phone, in the room, with connectivity switched off. This single request separates vendors who have built for these conditions from vendors who have read about it.
2. “What is the installed size, and what is the minimum Android version?”
Two numbers. They tell you whether anyone considered the actual devices in the field. An app requiring 180 MB and Android 12 will not install on the handsets most beneficiaries own. Safe Catch was capped at 25 MB and targets Android 7.0 — that constraint drove dozens of downstream decisions.
3. “Who owns the source code the day after handover?”
If the answer runs longer than a sentence, you have found a problem. A great many organisations discover years later that their vendor still controls the codebase, the app store listing, or both — which means the next round of changes has exactly one possible supplier, at whatever price they name.
4. “What data does it collect, and where does it go?”
For programmes serving vulnerable or politically exposed populations, the correct answer is often “as little as possible.” Safe Catch collects no personal data and stores progress only on the user’s own device. Location is accessed only when the user triggers an emergency alert. That was a deliberate protection decision, not a technical shortcut.
5. “What does year two cost?”
Every app has recurring costs: app store fees, hosting, domain renewal, and support. These are usually small and always predictable. What matters is that they are written down before the grant closes, so the partner is not surprised by them in a year when there is no funding line to absorb them.
6. “Who will maintain this after our grant period ends?”
Sustainability is the question most often asked in a proposal template and least often answered seriously. If the answer is “the implementing partner,” the partner needs the code, the accounts, the documentation and either in-house capacity or a budgeted local vendor.
Design decisions that decide adoption
Beyond connectivity, three field realities determine whether a tool gets used or abandoned.
Literacy
If any part of the app requires reading paragraphs, a substantial share of your intended users are excluded. The fix is not simplified language — it is audio.
Every screen in Safe Catch carries a speaker button that reads the content aloud in the user’s chosen language. The training is built as one picture, one short sentence, one audio clip per screen. Someone who cannot read at all can complete the entire course.
Audio narration is also the line item most frequently cut when budgets tighten, which is precisely backwards. For a low-literacy audience, the narration is the product.
Language, specifically
“Available in local language” is not a specification. Which language, which dialect, recorded by whom?
Safe Catch is narrated in English, Urdu and Balochi — and the Balochi uses the Makrani dialect spoken on that particular stretch of coast, not a generic recording from elsewhere in the province. It was re-recorded until the field team confirmed it sounded local. Users notice this immediately and it affects whether they trust the tool.
The physical environment
Screens that look immaculate on a monitor can be unreadable in direct equatorial sun. Buttons sized for an office user fail for someone with wet hands on a moving boat, or gloves in a cold store, or one hand occupied.
Budget for testing in the actual environment, not just user acceptance testing in a partner office. It is a small line item that changes outcomes.
Structuring the work: local delivery and the localization agenda
US funders have spent several years pushing toward locally-led development — channelling more funding through organisations based in the countries where programmes run, rather than through intermediaries in Washington or New York.
Technology procurement has been slower to follow. Software for a programme in Sindh or Turkana or Chiapas is still frequently contracted to a US or European agency at US or European rates, with no team who has ever visited the deployment site.
There is a middle path worth considering: a vendor with a contracting entity in a jurisdiction your finance and legal teams recognise, and a delivery team based in or near the region. That gives you familiar contracting, audit and accountability while the engineering, language work and field testing happen close to the users.
JahaSoft is structured this way. JahaSoft LLC is registered with the Texas Secretary of State, with a registered office in Austin. Our engineering, design and language teams are in Pakistan. On Safe Catch, that meant a US- and UK-comprehensible contracting relationship on one side, and staff who speak Balochi and could travel to Gwadar for field testing on the other.
Budget realities
A few things worth knowing before you review a quote.
Offline-first costs more than connected. Not dramatically, but noticeably. Anyone quoting the same price for both has not understood the requirement.
Multilingual audio is a production cost, not a software cost. Voice casting, studio time, re-recording and timing all sit outside the development estimate. Ask whether it is included.
Platform choice matters more than it seems. An Android-only build is substantially cheaper than Android plus iOS. In most field programmes in low-income regions, Android represents nearly all devices in use. Paying for iOS coverage that serves almost no beneficiaries is a common and avoidable overspend — though it may be justified if programme staff or partner organisations use iPhones.
Recurring costs are small and knowable. Google Play charges a one-time developer registration fee with no annual renewal. Apple charges an annual Developer Program fee. Hosting and domain renewal for any web or admin component are modest annual costs. There should be nothing beyond these.
If you want a broader sense of pricing before scoping, our guide to custom software development costs breaks down what drives estimates up and down.
Measurement: build the M&E in, don’t bolt it on
Most grant-funded apps report one number: downloads. That number is close to meaningless.
What a program officer actually needs is completion rates by module, active usage over time rather than at launch, pre and post knowledge scores, and — where relevant — whether the tool was used in the situations it was built for.
All of this is straightforward if it is designed in from the beginning. It is expensive and often impossible to retrofit. Put your indicators in the technical specification, not just the logframe.
For Safe Catch, pre- and post-training assessment was built into the app itself, so knowledge change is captured without a separate survey exercise.
A worked example
Safe Catch is live on the Google Play Store and free to download:
View Safe Catch on Google Play
Briefly, what it does: emergency SOS that transmits GPS coordinates over 2G SMS with no data connection; a Bluetooth relay so an alert can hop boat-to-boat until one vessel has coverage; an audio alarm and Morse code camera flash for visibility at night; seven-day weather forecasts stored on the device and refreshed automatically whenever a connection appears; full-screen severe weather warnings; and a five-module safety training course narrated in three languages.
All source code, design assets and app store ownership transferred to the implementing partner on delivery. The organisation owns what the grant paid for.
The detail of how the delivery was structured, including the governance and IP arrangements, is written up on our UK site: Delivering a UK Foundation-Funded Safety App in Pakistan.
Working with us
We build software for environments where the standard assumptions do not hold — no reliable connectivity, low literacy, low-cost devices, multiple languages, and users who will abandon anything that is difficult. The same engineering discipline applies whether the deployment is a fishing community in Balochistan or a field operations team in West Texas working beyond cell coverage.
If you are scoping a technology component for a field programme, we are glad to talk it through before the specification is written. A short conversation at the scoping stage routinely prevents expensive rework later.
Telephone: (+1) 512 202 0411
Email: [email protected]
JahaSoft LLC — 5900 Balcones Drive, STE 100, Austin, TX 78731
Offline-first means the application stores all the data it needs on the device itself and works completely without an internet connection. When connectivity becomes available, it synchronises in the background automatically. This differs from a conventional app, which requests data from a server each time it is used and stops working when the connection drops.
The most common causes are a dependence on connectivity the users do not have, a design that assumes literacy the users do not have, an installed size or operating system requirement the users’ phones cannot meet, and no plan for maintenance after the grant period ends. All four are identifiable before development starts.
It depends on scope, languages, platform coverage and the complexity of the field constraints. Offline-first architecture, multilingual audio and SMS or Bluetooth communication layers each add engineering effort compared with a conventional connected app. We provide fixed written quotations after a scoping conversation, with no undisclosed recurring fees.
In most low-income and rural regions, Android accounts for nearly all devices in the beneficiary population, and an Android-only build costs substantially less. iOS coverage is worth funding when programme staff, partner organisations or a donor-facing audience will use the app on iPhones. It is worth checking device data for your specific population before paying for both.
The implementing organisation, in almost every case. Full transfer of source code, design files and app store account ownership should be written into the contract before development begins. Without it, the organisation may be unable to change or maintain the tool it paid for.
Yes. The underlying architecture — local storage, background synchronisation, SMS alerting, multilingual audio and peer-to-peer relay — transfers directly to health, agriculture, education, disaster response and protection programmes in any low-connectivity setting. The content, languages and workflows change; the engineering foundation does not.
Yes. JahaSoft LLC is registered with the Texas Secretary of State and works with foundations, nonprofits, INGOs and commercial clients in the United States and internationally. Call us on (+1) 512 202 0411 or email [email protected].