When foreign advice says "put your business online," it imagines connectivity as a settled, invisible, essentially free background utility — like air. For a business and its customers in Tanzania, connectivity is none of those things. It is metered, it is bought in bundles, it is a real and visible line in people's budgets, and it shapes whether your digital product gets used at all. A beautiful app that burns through a customer's data bundle is an app they will quietly stop opening.
This is the economics behind the engineering. I have written separately about building software that survives unreliable power and patchy connections; this essay is about the cost side — the money your customers spend to reach you, and why understanding it is the difference between a digital product that gets used and one that gets admired once and abandoned.
Data is bought, watched, and rationed
Start with the lived reality most foreign software is not designed for: a great many Tanzanians access the internet through mobile data bought in bundles, and they watch that balance closely. Data is not an unlimited tap. It is a finite thing you purchase, that runs out, that you decide whether to spend on this or that.
This changes everything about how people use the internet. They are conscious of what they download. They notice an app that eats their bundle and resent it. They may turn data off entirely between deliberate uses. They choose, in a way the always-connected world has forgotten, whether reaching your business is worth the data it costs them. Your product is not competing only against other products. It is competing against the customer's own decision to conserve their bundle for something else.
Your digital product is not only competing with other products. It is competing with your customer's decision to save their data bundle for something they value more.
Heavy is the same as broken
The practical consequence: a data-hungry product is, for much of your market, a broken product — even when it works perfectly.
A website stuffed with huge images that load slowly and devour data is not "a bit slow." To a customer watching their bundle, it is a product that costs too much to use, and they will avoid it. An app that constantly syncs in the background, auto-plays video, and re-downloads things it already had is, to that customer, a thief — it spends their money while they are not looking. They may not articulate it as "high data usage." They will just feel that your thing is expensive to deal with, and drift to a competitor whose thing is light.
So "make it lightweight" is not a nice-to-have or a performance nicety here. It is a core requirement for the product being usable by your actual customers. The lightest competitor, all else equal, often wins — not because it is more elegant, but because it is cheaper for the customer to use, in a currency the customer is actively counting.
Designing for the cost of data
Building for connectivity economics means treating your customers' data as a real cost you are spending on their behalf — because you are. Concretely:
- Be ruthless about weight. Compress images hard, avoid heavy media that loads automatically, and do not ship megabytes where kilobytes would do. Every unnecessary byte is the customer's money, spent without their consent.
- Never re-download what has not changed. A product that re-fetches the same things every time it opens is burning bundles for nothing. Things that have not changed should not be paid for twice.
- Let the customer choose the expensive actions. Heavy downloads — a big file, a video, a detailed report — should happen when the customer decides, not automatically. Give them the choice to spend their data, rather than spending it for them.
- Make the essential version cheap. The core thing your product does should work at minimal data cost. Save the rich, heavy experience for moments the customer has chosen and, ideally, for when they are on cheaper connections.
These are the same disciplines that make software fast and resilient. The connectivity-cost lens just adds a sharp economic reason to take them seriously: here, waste is not inefficiency, it is the customer's money.
The opportunity inside the constraint
It is easy to read all this as limitation, but there is real opportunity in it, and the businesses that see it win.
Because so much software — especially software designed elsewhere — ignores connectivity cost, a product that takes it seriously stands out immediately to customers who feel the difference in their pockets. "This one doesn't eat my data" is a genuine competitive advantage, even if customers never say it in those words. They simply find your thing easy and cheap to use, and keep coming back, while the data-hungry alternatives quietly lose them.
Designing for the real cost of being online is therefore not just defensive. It is a way to be the product people actually keep on their phone, in a market where phone space and data budget are both scarce and contested. The constraint, taken seriously, is a moat against every competitor too connected to notice it exists.
The takeaway
"Put it online" is not free, and the cost falls on your customers in data they are actively counting. In Tanzania, connectivity is metered, watched, and rationed, which means a heavy product is a broken product no matter how well it works. Treat your customers' data as money you are spending for them: keep things light, never re-download the unchanged, let them choose the expensive actions, and make the essential version cheap to reach.
Do this and your product becomes one of the few that is genuinely affordable to use — which, for the majority of the market, is the same as being usable at all. The engineering of resilience and the economics of data point at the same design. Build the light, frugal, respectful version, and you build the one that survives on a real customer's real phone.