In October 2026, sign-in to Tari, our personal finance app, started failing on a phone in Cameroon. Not on every network, and not on every device. On Wi-Fi, everything worked. On mobile data, the app could not reach our server.

This is the story of that bug, because it can hit any developer serving users in Cameroon, and it is not where most people would look first.

The symptom

On Wi-Fi: sign-in worked.
On mobile data (LTE, a Cameroonian carrier): sign-in failed with a network error.
On mobile data with a public DNS resolver (1.1.1.1): sign-in worked again.

That last line gave it away. The network could reach our server; it just could not find it. The problem was DNS.

The cause

Our backend runs on Render, a cloud hosting platform. Every service there gets a default address ending in onrender.com. Our API was at api.tarifinance.com, set up the usual way: a CNAME record pointing our name at the Render address.

The carrier’s DNS resolver blocks *.onrender.com. And because a CNAME is just an alias, the resolver follows it, sees onrender.com in the chain, and refuses to answer. Our own domain did not protect us; it pointed straight at the blocked name.

The fix

We replaced the CNAME with an A record: api.tarifinance.com now points directly at Render’s IP address, with no onrender.com anywhere in the lookup. We kept the record DNS-only (no proxy), so requests go straight to the server.

The fix went live on 28 October 2026. The web app picked it up immediately. The mobile app needed a new store build, because the API address ships inside the app.

What we learned

Test on local mobile data, not just Wi-Fi. In Cameroon, many people are online mainly through their phone’s data plan. Office Wi-Fi hides problems like this one.
Never point clients at a platform’s default domain. That includes CNAMEs to it. Use your own domain with an A record, or a proxy you control.
Switching DNS is a great diagnostic. If an app works with 1.1.1.1 or 8.8.8.8 but not with the carrier’s resolver, look at DNS before you look at your code.
Keep the API address configurable. Mobile apps only change with a new release. A remote config, or a stable domain you own from day one, saves you a store review when something like this happens.

Building for real networks

This is the kind of problem you only find by shipping to real users, on real networks, and listening when they report something odd. It is also why we run our own apps: every lesson like this one goes straight into the products we build for clients.

Building an app for users in Cameroon or across Africa? Talk to us. We have already hit some of the potholes.