Here's a mistake I've watched kill the margins of good African software businesses: they price their product in local currency, feel good about being "accessible," and then watch inflation and devaluation quietly eat their revenue alive. Six months later the same subscription that felt fair is worth a third less in real terms, and they're effectively working for free.
Pricing is one of the least-discussed and most consequential decisions an African SaaS founder makes. In a stable, single-currency economy you can copy a US playbook. In a market with a volatile local currency — or two currencies at once — pricing becomes a survival skill. So let me lay out a position I've come to hold strongly: for most African SaaS, you should price in USD and bill in local currency. Here's what that means and why it works.
The core problem: your costs and revenue live in different currencies
Start with the structural trap. Your costs are substantially in hard currency — cloud hosting billed in USD, the APIs you depend on, the international tools your team uses, often the talent market you compete in. But if you price in local currency, your revenue is in a unit that's losing value against those costs, sometimes fast.
When the local currency devalues, your USD-denominated costs stay the same or rise, while your local-currency revenue buys fewer of those dollars. Your margin gets squeezed from both ends, and you didn't do anything wrong — the currency did it to you. Price purely in a depreciating local unit and you've built a business that structurally bleeds value every time the exchange rate moves against you. In a country like Zimbabwe, where that movement can be sharp and frequent, this isn't a tail risk. It's Tuesday.
Why "just price in USD" isn't the whole answer either
The obvious fix is to price and charge in USD, and some businesses do. But this creates its own problems, especially for products serving local customers.
Many customers earn in local currency and think in local currency. A pure-USD price can feel foreign, exclusionary, or simply hard to pay if their mobile money and bank accounts are local. In dual-currency economies you also run into the practical friction of which wallet the money comes from. And depending on the market and moment, there can be regulatory or optics reasons not to demand hard currency from local customers. So pure-USD pricing can shrink your addressable market to only those who hold dollars — which, for a mass-market product, is leaving most of your customers on the table.
This is the tension: price in local currency and inflation kills you; price in USD and accessibility kills you. The resolution is to separate the two decisions.
The playbook: USD as the anchor, local currency as the rail
Here's the approach that threads the needle. Denominate your price in USD — that's your source of truth — but let customers pay in local currency at the current exchange rate.
Concretely: your plan is "$20/month." Internally, that USD figure is what your pricing, your margins, and your financial model are built on. But when a local customer checks out, they see and pay the local-currency equivalent of $20 at today's rate. When the rate moves, the local-currency amount they pay moves with it — so your real revenue stays constant in the currency your costs are in.
Anchor in USD, Bill in Local Currency
e.g. $20/month] --> B[Apply current
exchange rate at billing] B --> C[Customer sees + pays
local-currency equivalent] C --> D[You capture stable
USD-equivalent revenue] D --> E[Margins protected
against devaluation]
This gives you the best of both. Your business is protected from devaluation because your prices are effectively pegged to your costs. Your customers get accessibility and familiarity because they pay in the currency they actually hold, through the rails they already use — mobile money, local bank transfer. The exchange-rate risk that would otherwise destroy you is neutralised, because it's passed through transparently at the moment of billing rather than absorbed silently over months.
The details that make or break it
The idea is simple; the execution has sharp edges. A few things I'd insist on:
- Be transparent about the rate. Show customers the USD anchor and the rate you're applying. Nothing erodes trust faster than a price that jumps between billing cycles with no explanation. "This plan is $20, charged at today's rate of X" is honest and defensible; a silently changing local number feels like a scam even when it isn't.
- Pick your rate source deliberately and disclose it. Official rate, interbank rate, or your own applied rate — these differ, sometimes a lot. Choose one, be consistent, and tell customers which. The rate is a first-class thing, not an afterthought.
- Decide how often you re-rate. Daily re-pricing is jarring on a monthly plan; never re-pricing defeats the purpose. Re-rate at each billing cycle, or hold a rate for a set period — and communicate the policy up front.
- Handle the dual-currency case explicitly. In markets like Zimbabwe, some customers have USD and would rather pay in it. Offer both — pay in USD directly, or pay the local equivalent — and capture the same USD value either way.
- Consider purchasing-power tiers, not just conversion. Straight conversion protects your margin but can still price out local customers if your USD anchor was set for a richer market. Sometimes the right move is a genuinely lower USD anchor for a local market — accessibility by design — not just converting a first-world price.
The takeaway
Pricing in a volatile-currency economy isn't a detail you sort out later — it's a structural decision that determines whether your margins survive contact with reality. The founders who get burned are the ones who picked local-currency pricing because it felt friendly, and discovered too late that "friendly" meant "slowly giving my product away."
The discipline that saves you is the same one that runs through every good African fintech system: treat currency as a first-class design decision. Anchor your value in the stable unit your costs live in, meet your customers on the rails and in the currency they actually use, and pass exchange-rate movement through transparently instead of eating it. Do that, and a volatile currency stops being the thing that quietly bankrupts you and becomes just another variable you've engineered around. Your customers stay served. Your margins stay intact. And you get to keep building.
