Industry
NGOs and development organisations
Development organisations operate where connectivity is unreliable, the data is sensitive enough to endanger people, and every pound has to be accounted for to a funder with its own reporting format.
Workflows
The work that actually happens here
Named the way practitioners in this sector name them, because that is the vocabulary a delivery team has to learn before it can be useful.
- Beneficiary registration
- Enrolling participants, often offline and in the field, with de-duplication and consent capture.
- Programme delivery tracking
- Recording activities, attendance and distributions against a logical framework.
- Monitoring and evaluation
- Collecting indicator data against a results framework, with verification and quality checks.
- Donor reporting
- Producing narrative and financial reports in each donor’s required format and cycle.
- Grant and budget management
- Tracking restricted funds against budget lines with the reallocation rules donors impose.
Constraints
What changes the architecture
These are the reasons a design that works elsewhere would be wrong here.
Offline-first is a requirement, not a feature
Field data collection happens without connectivity. Local capture with conflict-aware synchronisation is the baseline architecture.
Beneficiary data can endanger people
In some contexts, identifying data about participants creates real physical risk. Minimisation, encryption and access control are protection measures, not compliance boxes.
Donor requirements drive the data model
Each funder imposes indicators, formats and cycles. The model must accommodate several simultaneously without duplicate entry.
Devices and bandwidth are constrained
Field devices are older Android phones on metered data. Payload size is a design constraint.
Budgets are restricted and audited
Restricted funds cannot be moved freely between lines, and every allocation must be traceable.
Integrations
Systems we would expect to meet
- Mobile data collection tools such as KoboToolbox or ODK
- Accounting systems with restricted-fund tracking
- SMS and WhatsApp for participant communication
- Mobile money for disbursements in African markets
- Donor reporting portals
Trust considerations
What users and regulators need here
- Collect the minimum identifying data necessary, and consider whether a pseudonymous identifier is sufficient.
- Consent must be obtainable and meaningful in low-literacy and translated contexts.
- Devices are lost and seized; local data must be encrypted and remotely revocable.
- Participants should be able to understand and withdraw from data collection.
- Aggregated reporting must not allow re-identification of individuals in small cohorts.
Architecture
A shape we would actually propose
A starting sketch, not a template. Discovery is what turns this into a specific design with recorded trade-offs.
- Field client
- Offline-first mobile capture with encrypted local storage and conflict-aware synchronisation.
- Identity
- Pseudonymous participant identifiers with a separately controlled mapping to identifying data.
- Programme model
- Results framework as data, so multiple donor indicator sets map onto one activity record.
- Sync
- Compact, resumable synchronisation designed for metered, intermittent connections.
- Reporting
- Donor-format reporting generated from the operational record with small-cohort suppression.
Outcomes
What good looks like
- Field data captured reliably without connectivity
- One activity record satisfying several donor reporting formats
- Beneficiary data minimised and protected against device loss
- Restricted-fund tracking traceable to individual allocations
Next step
A ngos and development organisations project starts with the constraints
The Project Architect asks sector-specific questions about data, regulation and integration before it asks about features.