Why Western tech advice often fails in Tanzania

I read a lot of technology advice. Most of it is good — for the place it was written. The problem is that nearly all of it was written in San Francisco, London, or Bangalore, and it carries assumptions about the world that are simply not true in Dar es Salaam. The advice is not wrong so much as it is foreign. It solves problems we do not have and ignores the ones we do.

This essay is about the specific assumptions that break when Western tech advice crosses the border into Tanzania, and what the locally correct version of that advice looks like instead. I am writing it because I have watched too many good Tanzanian businesses follow excellent advice straight into a wall.

Assumption one: that the power stays on

Most software advice quietly assumes electricity. "Move your operations online." "Go paperless." "Run everything through the dashboard." All sensible — if the dashboard is reachable. In much of the country, power and connectivity are not guarantees, they are probabilities. A system that only works when the internet is up is a system that does not work on the days you most need it.

The Western answer to this is "improve the infrastructure." That is not advice you can act on. You cannot fix the national grid before you open your shop on Monday. So the locally correct version is different: design for the outage, not against it.

That means software that keeps working offline and syncs when the connection returns. It means a paper fallback that is not an embarrassment but a deliberate part of the system. It means never building a process whose failure mode is "we cannot serve any customer until the network comes back." The businesses that thrive here are not the ones with the best connection. They are the ones whose operations survive a bad connection gracefully.

Assumption two: that software is cheaper than people

This is the deepest one, and the most invisible to outsiders. The entire economic logic of Silicon Valley software is labour is expensive, so automate it. A tool that saves one hour of an employee's time pays for itself instantly, because that hour is costly. So the advice is always: automate, automate, automate.

In Tanzania, the maths is different. Skilled labour is more affordable here, and good software — especially imported, dollar-priced software — is comparatively expensive. A subscription that is trivial for a London startup can be a meaningful monthly cost for a Tanzanian business earning in shillings. The Western instinct to "buy the tool" often produces a worse outcome than a well-trained person with a simple spreadsheet.

So the locally correct question is not "what can I automate?" It is "where is automation genuinely worth more than the person it replaces?" Sometimes the answer is clear: the repetitive, after-hours, error-prone work. But far more often, the right move here is to augment a capable employee rather than replace them with a costly subscription priced for an economy that is not ours.

Assumption three: that customers pay by card

Western commerce advice is built on cards: card checkout, card-on-file subscriptions, the whole machinery of recurring billing. In Tanzania, the real financial operating system is mobile money. M-Pesa, Tigo Pesa, Airtel Money — that is how customers actually move money, and it behaves nothing like a card.

Advice that assumes card rails leads businesses to build checkout flows their customers cannot use, and subscription models their customers will not tolerate. The locally correct version starts from how money actually moves here: a customer confirms a payment from their phone, you reconcile against a mobile-money statement, and "recurring billing" is often a person choosing to pay again rather than a card being silently charged.

This is not a limitation to apologise for. Mobile money is, in many ways, ahead of the card systems it is compared to. But you have to build for the rails you have, not the rails the advice assumes.

What good advice has in common

I do not want to leave the impression that all foreign advice is useless. The good advice — the kind that survives the trip — shares one quality: it describes a principle, not a configuration. "Reduce the number of steps between a customer's intention and their payment" is true everywhere. "Add Stripe card checkout" is the same principle wearing San Francisco's clothes.

The skill, for any Tanzanian founder reading imported advice, is to strip the configuration off and keep the principle underneath. Ask: what is the human truth this advice is pointing at? Then implement that truth using the power, the labour economics, and the payment rails you actually have.

What to do with this

Three habits will protect you from most imported-advice mistakes:

• Translate, do not import. When you read a tactic that worked abroad, find the principle under it and re-implement the principle locally. Never copy the configuration.
• Cost things in shillings and in reality. Before adopting any tool, ask what it costs in a bad month, in your currency, when the connection is poor. If it only works in the good months, it does not work.
• Build from the customer you have. Your customer's phone, your customer's connection, your customer's mobile-money wallet — these are your real platform. Design for them, not for the abstract "user" the advice imagines.

The goal is not to reject the wider world's knowledge. It is to stop being its test market. Tanzanian businesses have a real, hard-won understanding of how technology works under our conditions. The best advice you will ever get is the advice that already assumes those conditions — and most of the time, that advice has to be written here, by people building here.