Building for under privileged communities in Africa

Brighton Mboya 2023-09-29

A note to business developers and software engineers who are building solutions for under priviledged communities in Africa.

According to a report published by GSMA in 2022, 83% of people living in Sub-Saharan Africa are still under 3G coverage with an average download speed of 7.5 Mbps. This data gives a lot of insights into how users use your product when in production.

First, I would like to clarify what I mean by under priviledged communities; I mean a certain group of people who own low-end devices, might not have access to the internet all the time, the major form of banking is mobile banking, and don't know how to use the simple digital services as simple as even opening up a new Gmail account.

For the past 12 months, I have been building a service that allows farmers in Zambia to access market prices for their produce. We started pivoting into this idea in September 2022, and we launched around August 10, 2023, and now we serve at least 500 farmers. During this period, we learn tons of lessons both on the business side of things and on product development, and that is what I want to share in this article.

  1. Start small & Iterate

Once we started Shamba Data, we wanted to provide all forms of data and analytics to the farmers. We wanted to send them market price updates, farming inputs, satellite data, and whatnot. But we decided to narrow down the focus to just one aspect and make sure to get everything right. You should start with a solution that really addresses your users' pain points, and from there, start shipping minor updates until you cover your full product offering. This can also help you reduce the operational costs in the beginning since you will be limited to cash and resources while starting.

  1. Make your solution simple

This is where you need to spend more time and ensure your solution is simple enough for everyone to use. You can avoid things like email signing up, the majority of these people don't have emails, the ones that do might not even remember the password. You don't need to record first and last names as separate fields; this increases the time you spend signing up for the service before even using it. A good rule of thumb here is to make sure your users go through 3 steps or less to get to the thing they’re looking for.

  1. Users don't care about the tech stack you choose.

The tech stack you choose doesn't matter if it doesn't meet your user needs. Most of us engineers spend time perfecting that button border-radius and trying to get the perfect score on Lighthouse. But the truth is that it doesn't matter that much as long as the user is satisfied with what you had in the first place. I was guilty of this when I was building Shamba Data, and I was spending two days trying to lower the size of Javascript the client receives when I could have spent that time talking more to my users. This doesn't mean you should ship garbage code, though, as long as you get your basics right, such as whether the sight is responsive, does it load fast enough, and have you optimized your queries, your service will work just fine.

  1. Don’t aim for lots of automation.

You might easily think that you can build a product and spend less time doing on-ground operations and shift them digitally. This can lead to retarded growth since most of your users don't spend a lot of time on the internet, so they might not see the Facebook ad that you are running. Have field agents who will go and convert your users on the field and teach them how to use the product. Try doing cold phone calls and try to close customers, this worked well for us as we got our first 50 paid users by doing phone calls and closing them.

  1. Adopt easily and fast.

Anything can happen after launch, and some of the things you won't be able to fix yourself. A week after we launch our payment provider was down for at least 4 weeks and we couldn't accept payments automatically from our users. So we ended up cold calling the users and sending them our personal phone number to complete the payment. If you’re building a more complex service like an e-commerce store, you might not be able to utilize this method, but you have to adapt to these kinds of situations so that you move fast.

There are other things that you really need to spend time and think them though, things like your server and database locations etc. If your database and servers run on us-east-1, can your average user tolerate that latency, and how does it affect the user experience? Do you have the necessary resources to rack up your own servers so that you can work around this?

Also, do you have a reliable payment provider that can give you that smooth stripe developer experience for your payment of choice? It is 2023, and I still can't believe how frustrating it is to accept payments via mobile banking in some parts of the continent. A huge chunk of the population in Sub-Saharan Africa prefers to use mobile banking as compared to normal online banking, but integrating all these different mobile banking options smoothly and fast can be a headache in most countries.

And lastly, don't over-engineer your product. Seriously though, there are startups with more dedicated servers than users. Keep it simple and scale when you need to. You really don't need Kubernetes and dev-ops in your workflow when you first launch.

Hopefully, you found our story interesting and picked up lessons that you can use.