Building in Africa, not for Africa

There's a distinction most tech entrepreneurs miss.

Building for Africa means taking a product designed elsewhere and adapting it.

Building in Africa means starting from local constraints as your design foundation.

The result is architecturally different.

Constraints aren't problems to solve

When I started building a sales agent for the Beninese market, I could have ignored the local specifics.

Used the official WhatsApp API (expensive, restrictive). Used cloud models (unpredictable latency, cost in foreign currency). Targeted SMEs that use email and CRM the way they do in Europe.

Instead, I let the constraints drive the architecture.

SMEs respond on WhatsApp, not by email. Cloud APIs billed in dollars create a cost structure that doesn't hold up at this stage. Connectivity isn't guaranteed — agents need to work locally.

Every constraint was a forced architecture decision. And every forced decision kept me from building something useless.

Why WhatsApp isn't an "alternative channel" here

In Europe, email is the default professional channel. WhatsApp is the personal one.

Here, it's reversed.

A restaurant in Cotonou doesn't necessarily have a professional email set up. It has WhatsApp. It opens it 40 times a day. Business decisions run through there.

Designing a prospecting system with email as the priority and WhatsApp as an option is building for a different market than the one you're targeting.

This isn't a user preference. It's a sociological fact. The channel hierarchy has to be flipped in the code.

The bug nobody documents

Benin changed its phone number format: 8 digits → 10 digits with a 01 prefix.

Google Maps returns the new format. No npm library handles it. No tutorial anticipates it.

// phoneToJid() — the two Benin formats
if (cleaned.length === 10) return `229${cleaned}@s.whatsapp.net`;  // 01XXXXXXXX
if (cleaned.length === 8)  return `22901${cleaned}@s.whatsapp.net`; // old format

These 4 lines don't exist in any package. They exist only because I built this in the market, on the ground.

That's the kind of knowledge you can't acquire remotely.

The economics of a local LLM

Using GPT-4 for every generated WhatsApp message: about €0.02 per message.

100 messages/day × 30 days = €60/month just for generation.

In a market where the average ticket is 150,000 XOF (~€230) for a full project, that cost structure eats into your margins.

With Ollama running locally (qwen2.5:7b, CPU): zero marginal cost after setup.

This isn't a technical trade-off. It's a business model choice. A local LLM enables patterns you wouldn't risk with a billed API: generating 50 messages in bulk, analyzing patterns in the background, following up with every dormant prospect without pre-calculating ROI.

What that produces, architecturally

An agent that works without an internet connection for inference. A priority contact channel (WhatsApp) and a fallback (email). Handling of local formats — phone numbers, currency in XOF with no decimals, send times adapted to local habits. Persistent memory that survives connection drops.

These aren't workarounds. This is the native architecture of this market.

The real lesson

"Emerging" markets aren't markets running behind on some linear curve.

They have their own equilibria, their own channels, their own economic constraints.

Building from these constraints produces solutions that wouldn't have been born elsewhere — and that are hard to copy for someone who doesn't live in this context.

That's the advantage of building in Africa, not for Africa.

→ The agent, not the employee → Devlog: 4 months building the agent