In settings where technology is scarce, innovation becomes much more than a luxury; it becomes a part of the necessity.

Digital inclusion has slowly become a growing need for our world today; however, a striking difference between rural and urban centers still exists. To illustrate, internet connectivity in Kenya is pegged at 42.5% around urban centers, while rural centers are much lower at 13.7%.

All these issues pose unique challenges to the deployment of technology solutions in emerging markets. We had to grapple with them while devising an NFC-based solution for a food distribution program that will ensure identity and accountability in remote areas commonly characterized by scarce access to technology.

So often, people speak of the need for innovation in emerging markets; it just doesn't get the due emphasis in the actual solution. I'm Martin Nyaga, CTO at Terra Softworks. In this blog post, I'll describe the development process of a custom NFC solution for a feeding program in Kenya: tackling hard realities, such as low internet connectivity and offline functionality, to make secure data handling in a way that truly works for the people using it. I will be showing readers what it is like in real time to innovate in emerging markets with hands-on looks.

Background

Ever since we set out to scale our feeding solution, Tap2Eat, to serve over 150,000 children every day, we knew we would be in for a good fight. It was designed to streamline meal distribution in schools: every transaction tracked and accounted for. But as we started to scale, it quickly became clear that an online model alone just wouldn't suffice. You see, other payment or transaction systems have the activity spread out over time, but lunch is different; everyone is trying to eat at the same time.

I mean, I fully realize that we could have scaled up our servers to handle the load, but when you're dealing with a relief program, cost is huge and some sort of over-reliance on cloud infrastructure was not feasible.

So, why not work offline? It seemed easy: just keep a local copy of parents' balances, process transactions at lunch, and then sync everything back online afterward when the rush is over. Easy, right? Well, as it turned out, not really. The difficulties in building an offline solution were way more sophisticated than what we had earlier thought.

The Connectivity Challenge

As we plunged deep into the development of Tap2Eat, we indeed realized that going offline was to bring along a plethora of problems at our doorstep, particularly in respect of the internet connectivity issue.

While I could write an entire series on all the issues we had to face, let's talk about one of the biggest hurdles: how to make sure the system works seamlessly even when connectivity is spotty or nonexistent.

Our primary goal was simple: parents had to be able to pay, their child had to be identified and receive a meal, and the parent had to receive notification that everything went well.

Pretty simple online, but once you add in the requirement to do it offline, suddenly the complexity snowballs—the requirements creep up, and creep up very fast.

First off is the problem of double transactions.

The child uses their wristband on two devices somewhere, and presto, instead of one, he has two meals. If the meals are on a subsidy, this becomes a big problem.

The parent is only paying a small portion; the rest is covered by the organization and can therefore be financially pressured by any slip-up on the part of the program.

Then there is the issue of siblings.

Imagine having an account with two children but having the parent only pay for one meal. It becomes a bit complicated when the children are in different schools, both schools under the Tap2Eat program, or perhaps in the same school but with different devices.

The system will have to make sure it is the right child receiving the meal that is paid for to prevent any mix-ups.

And let's not forget the top-up issue.

What if a parent tops up their balance after it's already been drawn down to the device? If the device goes offline, it gets pretty difficult to assure a child they will get their meal. Plus, a device could lose its charge or freeze, preventing it from syncing the transaction to the main server, and presto—out comes disorder.

These are some of the connectivity challenges we were up against: every single one would present a unique problem that made us put our thinking caps on and come up with robust solutions.

The Solution: NFC Wristbands and Cross-Device Sync

Our first armor to combat these connectivity problems lay within the support for NFC wristbands.

The great thing with NFC technology is that it's both read and write, allowing us to write small payloads of data, so we could update the wristband once the child had gotten their meal. If the same wristband was scanned outside the designated period of time, the system would flag it, ensuring that the double-dipping could not occur. Solid plan, right? Well, no. Here's where things got tricky.

NFC has a small but critical limitation: the fact that it takes a bit of time in reading and writing data, sometimes up to 2 seconds. That does not seem like much, but when you have a school that had 2,000 kids, all trying to get their meal within a narrow window, those seconds really stacked up. And when the lines were long, the device operators—whom we called Tap2Eat School Manager (TSM for short)—would sometimes just tap the band quickly, not giving the system enough time to write the data properly.

As a result, our NFC solution became spotty; it worked sometimes and not others. Realizing we needed an extra layer of protection, we came up with cross-device sync.

So, this is how it worked: the devices scanned their surroundings and detected other similar devices within their range, therefore creating a mesh network based upon either Wi-Fi or Bluetooth connection.

This enabled them to synchronize the data between devices around them, making sure information regarding secure existence would be possible, provided there was a copy of the same local database. This meant that, if one device missed a write to an NFC band, the chances were quite high that other devices did catch it, so the necessary data was on hand to keep that from happening.

This kind of synchronization across devices was important to ensure that our system kept working, even if the NFC technology did fail us. It gave us the backup we needed to make sure the right kids got their meals—no matter what.

Enhancing the System: Sibling Management and Smart Syncing

Even though our NFC wristbands and cross-device syncing were in place, we still had a couple of big issues to address. The main one was meal allocation between schools in the same Tap2Eat program, especially in cases where sibling schools were involved. Another was the problem where parents topped up their accounts after the device had already synced. We needed something that wouldn't bog down our system or create reconciliation nightmares at the end of the day.

So we designed an algorithm that could handle these tricky situations.

First, it checked how many siblings a parent had, and checked if the parent had enough funds at that point in time to pay for all their kids' meals.

It would also consider the parent's behavior; were they regular users, who perhaps only just didn't top-off their accounts? Or maybe people who become inactive over time and eventually dropped-off from the program. We then had the server prioritize online checks on only those few flagged accounts.

This way, the load on our servers was hugely reduced, and we could be sure there would not be reconciliation issues in the future. The business intelligence that also ensued; using the data acquired to predict meal needs in certain areas and tell who is needy between parents should take an entire chapter writing, not today. For now, this system allowed us to keep things running smoothly, even when dealing with the unpredictable nature of offline transactions.

Challenges and Lessons Learned

Building Tap2Eat wasn't without its share of hurdles, and the lessons we learned along the way were invaluable. The greatest challenge was to work with minimal connectivity while delivering a reliable system. It is one thing to design a solution in a well-connected environment, but when dealing with rural areas that mostly have spotty internet access at best, the ball game changes drastically.

What we learned was that some theoretically well-suited technology for the task was not enough. Such a technological constraint, specifically the delay in read/write, teaches us that technical limitations, no matter how small, get proportionally magnified once we scale. That is what made us creative and led to our solution for cross-device synchronization. That was a reminder that the emerging market systems are currently to be built with layers of redundancy and backup, where the operating environment is anything but predictable.

I learned how to appreciate user behavior and take that into account with the design. The algorithm that we built to take care of sibling meals and top-ups wasn't just a technical solution, though; it explained to us how parents interact with our system so that it was designed within these rules. That was how we managed to strike a good balance between system performance and user fairness.

In a word, sometimes the stupidest ideas are the best. Our shift to offline syncing wasn't at all what we had in mind, but it turned out to be the secret sauce that made Tap2Eat work. It taught us that you need to be very supple and quick on your feet when innovating in the emerging markets.

In creating Tap2Eat, we adapted specifically to the moments of struggle faced by emerging markets. This exercise of developing solutions—practical, resilient innovation—has found its path from solving problems of restricted internet connectivity to issues of dynamic, real-time transactions: tested problems, solved problems, motivating us to think out of the box.

Needless to say, as we continue honing and enhancing Tap2Eat, there is much to learn from what we have been through. Innovation in developing countries is not just about transferring existing technologies but, at the same time, understands specific needs and limitations that are part of the environment you are part of, creating solutions that can survive within those requirements.

Conclusion

I hope this deep dive into our experience with Tap2Eat sheds some light on what it means to build successful technology solutions for emerging markets. And who knows—in a future article, maybe I might even open up more about how we are making use of data to be predictive of meal requirements and which families need it more. In the meantime, one point seems clear: it is the adaptability within emerging markets that is the source of innovation.