When you build software for enterprise clients in Auckland or Wellington, you assume a few things: reliable internet, modern devices, users who are broadly familiar with digital tools. When you build for organisations in the Pacific, you assume none of those things. And that changes everything about how you approach the work.
What You Need to Know
- Infrastructure in Pacific Island nations is variable: internet, power, and device quality can't be assumed
- Software must work offline or degrade gracefully. Losing data because of connectivity is not acceptable
- Impact measurement in development contexts requires different approaches than commercial ROI
- The best technology choices are often the simplest and most resilient
The Infrastructure Reality
I'm not going to romanticise this. Building software for deployment in the Pacific means working within constraints that most New Zealand developers have never encountered.
Internet connectivity varies from reasonable in urban centres to intermittent or absent in rural areas. In Samoa, internet penetration sits around 34%, and connection speeds in many areas make loading a modern web application painful.
34%
internet penetration rate in Samoa as of 2021
Source: ITU World Telecommunication Indicators, 2021
Power supply is variable. Outages happen, especially during cyclone season. A system that requires constant connectivity and power to function is a system that doesn't function for significant portions of the year.
Devices range from current-generation smartphones to older Android phones with limited storage and processing power. Building exclusively for the latest iPhone is building for an audience that doesn't exist in this context.
These aren't problems to solve. They're constraints to design within.
Offline-First Is Not Optional
The most important architectural decision we made on our Pacific projects was to build offline-first. The application works without a network connection. Data syncs when connectivity is available. Nothing is lost if the connection drops mid-task.
This isn't a progressive enhancement. It's the core architecture. The application should assume it's offline and treat connectivity as a bonus. This is the opposite of how most web applications are built, and it requires rethinking some fundamental patterns.
In the Pacific, your software has to work when the internet doesn't - that's not a nice-to-have, that's whether the software gets used at all.
Isaac Rolfe
Managing Director
Conflict resolution, when two people edit the same record offline and sync later, is the hardest part. We've adopted a last-write-wins approach for most fields, with explicit merge handling for critical data where conflicts could have real consequences.
Technology Choices for Resilient Systems
Our technology choices in this context are deliberately conservative.
Progressive web apps over native applications. One codebase, works on any device with a browser, supports offline via service workers. No app store dependency.
Lightweight frameworks over heavy client-side rendering. Every kilobyte matters when the connection is slow. Server-side rendering with minimal JavaScript means faster load times on low-powered devices.
Local data storage with background sync. IndexedDB on the client, sync queue for pending changes, conflict resolution on the server.
Simple UI patterns over complex interactions. Drag-and-drop, infinite scroll, real-time updates, these all assume fast, reliable connections. Simple forms with clear save buttons work everywhere.
Measuring Impact, Not Output
In commercial work, success is relatively easy to define. Revenue, user growth, conversion rates, cost reduction. In international development, the metrics are different and harder to capture.
The system we built isn't measured by how many records it processes. It's measured by whether vulnerable people receive better support. Whether case workers can do their jobs more effectively. Whether the organisation has the data it needs to advocate for resources and policy changes.
$150B
estimated annual losses from failed ICT for development projects globally
Source: World Bank, 2020
These outcomes take time to emerge. You can't measure them in a sprint review. They require longitudinal data collection, qualitative feedback from users and beneficiaries, and honest assessment of whether the technology is helping or just existing.
We've built measurement into the system itself: case resolution times, referral completion rates, worker satisfaction surveys, data completeness metrics. Not because these are the ultimate measure of success, but because they're leading indicators that tell you whether you're heading in the right direction.
What This Teaches About All Software
Working in the Pacific has made us better at building software for everyone. The constraints force clarity. When you can't rely on fast internet, you build efficient systems. When you can't rely on powerful devices, you build lightweight interfaces. When you can't assume digital literacy, you build intuitive workflows.
These are good practices everywhere. Most enterprise software is over-built, over-connected, and over-complicated. The Pacific work reminds us that the best software is the simplest software that solves the problem.