IS in Developing Countries: The Assumptions That Don't Travel

The question that keeps nagging me when I read mainstream IS theory is how many of the assumptions built into the foundational models are actually assumptions about a specific infrastructure context that never gets named as such. TAM assumes the user has a stable device and a working system to interact with. DeLone and McLean's IS success model assumes organizational structures capable of measuring use and user satisfaction. UTAUT assumes a workforce in a formal employment context with an IT department. None of these frameworks say "this model only applies in high-income countries with reliable electricity and broadband." But that is often what the sampling tells you if you look at where the data came from.

The IS for Development subfield, often called IS4D, takes this problem seriously. The ICTD community, Information and Communication Technologies for Development, has been building a research program around what actually happens when IS concepts meet infrastructure constraints, informal economic structures, and organizational contexts that look nothing like a North American enterprise. My honest read is that the main IS journals have been slow to integrate these questions at the theoretical level rather than treating IS4D as a specialized niche. The assumptions embedded in mainstream IS theory are treated as universal. They are not.

The M-PESA case is the one that gets cited most often, and for good reason. Launched by Safaricom in Kenya in 2007, M-PESA is a mobile phone-based money transfer and payment service. By the time it was a few years old, it had reached tens of millions of users and was handling a significant share of Kenya's domestic money transfers. What made M-PESA interesting from an IS perspective is not just that it worked. It is why it worked in a context where conventional banking infrastructure had not. Most Kenyans at the time did not have formal bank accounts. Fixed-line infrastructure was limited. The banking branch density in rural areas was low. M-PESA worked because it was designed around what people actually had, a mobile phone and a network of local agents who could handle cash in and cash out, rather than around the infrastructure that a high-income country financial system would take for granted. The IS design met the actual context. That is not a trivial design achievement.

The leapfrogging concept tries to name what happened in cases like M-PESA. The argument is that some low and middle income countries, rather than moving through the same technology stages that high-income countries went through in sequence, skip directly to newer alternatives. Fixed-line telephony was bypassed in favor of mobile. Physical banking branches were partially bypassed by mobile money. Desktop computing was partially bypassed by smartphone access. This pattern is widely discussed in the IS for Development literature, and I think it is descriptively accurate as a pattern even though the underlying mechanisms are debated. Leapfrogging is not inevitable and it is not frictionless. The skipped stages often represent capabilities that still matter, and moving directly to the later technology without the institutional scaffolding that the earlier stages built can create gaps that are not immediately obvious.

The infrastructure assumption problem shows up most concretely when you look at what IS systems presuppose. A system designed for always-on broadband fails visibly when connectivity is intermittent, which is the normal experience in many LMIC contexts. The failure mode is not just slower performance. It is data loss, session timeouts, synchronization errors, and accumulated frustration that eventually leads to abandonment. A system that assumes high device storage fails when users work with the cheapest available handsets, which often have limited storage and are shared among family members. A system that assumes formal organizational processes, documented workflows, job titles, and IT departments, fails when it is deployed in organizations that work through informal processes and social relationships rather than documented procedures. These are not unusual edge cases in LMIC contexts. They are the typical conditions.

The platform assumptions matter too. Many digital systems assume a reliable postal address, which is needed for identity verification, delivery logistics, and account registration. Large parts of sub-Saharan Africa and South and Southeast Asia do not use the address formats that Western postal systems were built around. This is not a minor inconvenience. It blocks whole categories of service from functioning at all. The what3words system and various national addressing initiatives have tried to address this, but the point I am making is that the IS systems were designed with an assumption that did not travel, and then engineers had to build workarounds for a constraint that was never acknowledged as a constraint in the original design.

What does it mean for IS theory that so many foundational models were built on these assumptions? I think it means two things. First, the generalizability claims made for those models are probably overstated. A model that predicts technology adoption in a sample of US corporate employees may not generalize to agricultural smallholders in a country with intermittent power. Second, the IS4D literature offers something valuable back to mainstream IS theory: a stress test. When you take a model into a context that violates its baseline assumptions, you discover which parts of the model are doing the theoretical work and which parts were just reflecting the context in which it was built. That is useful for any researcher who cares about theory as theory, not just as a local empirical regularity.

Gartner's research on technology adoption in emerging markets has noted that infrastructure and organizational contexts in those markets require different approaches than high-income country deployments, though I would hedge any specific quantitative claims about market size or adoption rates I have not independently verified. The directional observation, that you cannot simply port a high-income-country IS deployment into a different infrastructure context and expect it to work, is consistent with what the IS4D research community has been documenting for years. The mainstream practice of treating high-income-country IS models as the default and LMIC contexts as special cases might be exactly backwards. The LMIC context reveals the infrastructure assumptions that the default model was always making. It just never had to name them.