DevGateSoftware for governments and multilateral organizations—UN agencies, development banks, ministries—operates under constraints most commercial projects never face. It has to work in the field, exchange data with systems built decades apart, survive audits, and be documented well enough for the next vendor to take over.
Our work with the World Health Organization, the Asian Development Bank and SMEDA has taught us a few lessons worth sharing.
Build on open standards from day one
Interoperability isn't a feature you add later. On our WHO work—a Civil Registration and Vital Statistics (CRVS) application, and health data collection apps for Zambia and Indonesia built with partner ONA—we used HL7 FHIR, the Google FHIR SDK and Clinical Quality Language (CQL). Building on FHIR resources meant data could flow into existing health infrastructure instead of creating another silo.
Lesson: choose the relevant international standard (FHIR for health, for example) before designing your data model, not after.
Design for the field, not the office
Health workers and registrars often work far from reliable connectivity. Apps need to capture data offline, validate it on the device, and sync safely when a connection returns.
Lesson: treat offline-first as a core requirement. Test on the low-end Android devices people actually use, in the conditions they actually work in.
Integrate with what already exists
Large institutions rarely replace core systems wholesale. At the Asian Development Bank, our work on an Oracle E-Business Suite upgrade focused on Web Services integration, front-end improvements, performance tuning and security—so that the upgraded platform kept working with everything around it.
Lesson: budget as much effort for integration and regression testing as for new features.
Security and identity are part of the product
Public institutions hold sensitive data about citizens, patients and finances. Role-based access control, identity governance and audit trails need to be designed in—the same principles we applied implementing Oracle Identity Management for HBL in banking.
Lesson: define roles, permissions and audit requirements in the first sprint.
Document for procurement and handover
Multilateral and government clients often require past-performance write-ups, technical documentation, and a clean handover to local teams. Documentation written as you go is far cheaper than documentation reconstructed at the end.
Lesson: make architecture notes, runbooks and handover guides part of the definition of done.
A checklist for your next project
- Relevant open standards identified (FHIR, OpenID Connect, etc.)
- Offline and low-bandwidth scenarios specified and tested
- Integration points mapped and owned
- Roles, permissions and audit logging designed up front
- Security testing (VAPT, code review) scheduled before go-live
- Documentation and handover plan agreed
If you're preparing a bid or planning a public-sector digital project, request our capability statement or read the WHO case study.
Free guide
Choosing a software partner? Read the engagement models guide.
Models compared, a sample timeline and 8 questions to ask any vendor.