Why we built a cloud here
Every millisecond your users wait is a round trip to another continent. We think infrastructure for African products should sit on the same continent as the people using them.
If you build for users in Lagos, Nairobi or Accra and deploy to a region in Northern Virginia or Frankfurt, every request your users make crosses an ocean twice. That is not a configuration mistake — it is the default that most tooling quietly makes for you.
It shows up as latency you cannot optimise away in code. You can shave milliseconds off a query all week and lose them again on the way to the database.
Physics is not a tuning problem
You can cache aggressively at the edge, and you should. But the moment a request needs to write something, or read something a cache cannot serve, it goes back to wherever your database lives. No CDN fixes a write path.
Putting the whole stack — app, Postgres, Redis, Kafka, object storage — in the same place as your users is the only version of this that works.
Paying in the currency you earn in
The second problem has nothing to do with speed. Cloud bills arrive in dollars, on a card, at whatever the rate happens to be that month. For a business earning in naira, that turns a fixed infrastructure cost into a currency position nobody asked for.
We bill in naira and take local payment methods. Your infrastructure cost stops moving for reasons that have nothing to do with your infrastructure.
What we are building
- Managed Postgres, Redis and Kafka, with the defaults that fail quietly at small scale already fixed
- S3-compatible object storage that existing tooling talks to without changes
- Static sites, container deploys, and networking that includes real TCP and UDP proxying
- An MCP server, so AI coding agents can deploy to us directly
Building for this market should not mean accepting worse latency, or a bill denominated in someone else’s currency.
If you are running something here and paying an ocean of latency for it, we would like to hear what you are running.