The 20% Gatekeeper Tax and Building Bus-Proof Software

There is a specific kind of cold sweat you break when a service you rely on suddenly decides to tax your existence.

I was working out of a shared space in Gbagada yesterday, struggling with some erratic latency issues on a client's database, when the news broke about the US demanding a 20% "protection fee" to keep shipping lanes open in the Strait of Hormuz. On a massive scale, it is the ultimate landlord move. But to a developer, it felt instantly familiar.

It is the exact same feeling you get when a dominant API provider casually sends an email saying they are deprecating their free tier and locking basic endpoints behind a massive paywall. Suddenly, the toll booths are up, and you either pay the tax or watch your application break.

We are building in an era of digital gatekeepers, and if you do not design your systems to survive these sudden tolls, you are going to get left behind.

The Danger of the Single Point of Failure

The global supply chain relies on a few tiny, choke-point channels. If one closes, everything from microchips to the price of fuel in our local generators spikes.

We saw another kind of sudden shock this week with the sudden passing of US Senator Lindsey Graham and the quick scramble to fill his seat. It made me think about the fragility of human systems. In engineering, we call this the Bus Factor—how many key team members can get hit by a bus before the project completely stalls?

If your startup’s entire deployment pipeline, server credentials, or critical architecture lives in the head of just one person, you are running a high-risk operation. I have seen small teams in Akure and Lagos grind to a complete halt because the lead dev went off the grid for a weekend and nobody else had the SSH keys to the production server.

Building "bus-proof" systems means writing boring, clear documentation. It means setting up shared password managers, automating your deployments, and ensuring that no single person—not even the founder—is a bottleneck.

Engineering for Self-Reliance

When global shipping gets messy, hardware costs in places like Computer Village skyrocket. Suddenly, importing a clean testing device or a solid server stack feels like funding a minor space program.

So, how do we build software when the gatekeepers keep raising the prices?

First, we stop over-engineering. You probably do not need a massive microservices architecture running on a dozen costly AWS instances to serve a few thousand users in Owerri or Onitsha. Keep your stack lean. A single, well-optimized VPS running SQLite or a basic PostgreSQL database can handle a ridiculous amount of traffic if you write clean queries and cache aggressively.

Second, we embrace open-source alternatives. If a proprietary service can lock you out or hike their fees by 20% on a whim, you need a backup plan. Look at self-hosted analytics, open-source database engines, and local payment gateways that understand the terrain.

We have to adopt a "No gree for anybody" mindset with our tech stacks. Do not let external dependencies dictate whether your product lives or dies. Build it so you can swap out the plumbing whenever the landlord decides to raise the rent.