"Good enough for Nigeria" is a phrase that costs Nigerian customers a lot of money. We do not use it.
There is a soft prejudice in the way African software gets graded. Less uptime is forgiven. Less polish is excused. A product can ship with bugs that would be career ending elsewhere, and people will shrug because "it is Africa." That shrug is expensive — for the customer, the engineer, and the company.
What "good enough is not enough" means in practice
It is easy to say "we hold a high bar." It is harder to say what that actually means. For us it means four specific things.
1. Uptime is a number, not a feeling
Every BOU product has an explicit uptime target. We measure it. We publish it internally. If we miss it, we write up why. We do not say "the internet was bad that week." Internet being bad is something a real Nigerian software company has to plan for.
The point is not to hit four nines. The point is to know what we are aiming for and to know when we missed it.
2. Code review is not optional, even when we are slammed
Especially when we are slammed. The first thing teams under pressure want to drop is review. The first thing we refuse to drop is review. Bad code shipped under pressure is the most expensive code in the company; you pay for it for years afterwards.
Every PR at BOU gets reviewed. Even a one-line CSS fix. The cost of the review is small. The cost of skipping it adds up to entire weeks of debugging six months down the line.
3. Error budgets are real, not theatre
If a service is allowed to be down for four hours a quarter and we have used three of them in week two, we stop. We do not ship new features. We fix reliability first. This sounds like SRE textbook stuff. Most teams that say they do it, do not.
4. NDPR compliance from day one
Nigeria has a real data protection regulation. We treat it as a real constraint. Every product is designed to comply with NDPR from the first line of code, not retrofitted when a regulator notices. The cost of doing this on day one is a couple of weeks. The cost of retrofitting is months and reputational damage.
Why the bar matters more here, not less
The cynical argument goes: "Nigerian customers are price-sensitive, so they will tolerate worse software." That is a misreading of the market.
Nigerian customers tolerate worse software because they have no choice. The day a credible alternative shows up that does not break under load, they switch. We have seen it. We have benefited from it.
The other reason the bar matters more here: when something breaks in Nigeria, the support cost is brutal. There is no automated chat-and-resolve flow. There is a human who has to take a call. Reliable software pays for itself in support costs alone.
The cheapest engineering decision a Nigerian company can make is to hold a high bar early. Every shortcut you take now is a support call you will take in six months.
What we do not mean by "high bar"
We do not mean over-engineering. We do not mean adopting every microservice fad. We do not mean three-month code reviews. The simplest possible system that meets the bar is the right system.
We have a strong bias toward small systems with few moving parts. Boring databases. Plain Go services. Servers we can SSH into and understand. That is part of the bar, not against it. The simpler your system, the higher the real uptime, all else equal.
What the bar gets us
Products that work. Customers who stay. Engineers who learn how to ship real software instead of demos. Word-of-mouth that compounds because the second customer is referred by the first.
Over five years, this is the difference between a company that has to discount to keep customers and one that customers tell their friends about. Xtate is in the second category, mostly because we refused to be in the first.
An invitation
If you are building software in Nigeria and you have caught yourself saying "good enough for now," ask one more question: how much will it cost you to leave it like that for the next year? If the honest answer is "a lot," fix it now. The bar is not a luxury. It is the cheapest path.