The cost nobody puts in the pitch deck
Ask a founder what limits their growth and you will hear about talent, funding or customers. Ask an operations lead in Lagos what actually interrupted last week and the answer may be simpler: the power went off. Electricity is the quiet constraint underneath nearly every other plan.
This is not a complaint about any one country. It is an observation about how reliable power shapes technology businesses, and what builders can do when it is not guaranteed.
Where the constraint shows up
Software feels weightless, but it runs on machines that need power, in buildings that need cooling, connected by networks that need power too. When supply is unreliable, the effects spread in every direction.
Offices and studios run generators or inverters, and fuel or battery capacity becomes a line in the budget. Servers kept on premises need uninterruptible supplies. Mobile towers and network equipment depend on backup power, so connectivity can degrade when the grid fails. Staff working from home lose work hours to outages that are nobody's fault.
For a business, this means a cost that is both direct and variable. Diesel, solar installations, batteries and maintenance are real expenses. So is the lost productivity when none of them is enough. A company in a region with stable power does not carry these costs, which is one reason comparing operating budgets across markets can mislead.
What it does to product design
The more interesting effect is on what we build and how.
If a clinic's power fails during the day, its software should not lose a half completed patient record. If a point of sale terminal loses connection, the shop should still be able to sell. If a field agent's phone battery is low, the app should not demand a long sync before it will work.
This pushes designers toward several habits.
- Offline first behaviour. Let the application work without a connection, save locally, and reconcile when the network returns.
- Saving progressively. Never hold a long form hostage to a single submit.
- Light data use. Smaller payloads and efficient sync reduce both data cost and battery drain.
- Graceful recovery. Assume interruptions will happen mid operation and make resuming safe, so duplicate and partial actions are handled rather than hoped away.
Software built in markets with stable power often assumes none of this. The result is products that work well in a demo and badly in the field. Building for interruption tends to produce software that is better everywhere, since networks fail even in places with excellent grids.
Infrastructure decisions get harder
Hosting is another place where energy is part of the decision. Running serious computing capacity locally means securing power, cooling and connectivity at a scale few small companies can manage. Many therefore rely on cloud regions elsewhere, which brings latency and, where rules require it, data residency questions.
Meanwhile, the growth of compute heavy workloads, including machine learning, makes electricity use a more visible cost for everyone. Where power is expensive or scarce, efficiency stops being a nicety. Choosing a smaller model, caching results and avoiding wasteful processing are economic decisions as much as technical ones.
Practical responses
For a team operating where power is uncertain, a few measures pay back reliably.
Make an honest inventory of what must stay up. Not everything needs the same protection. Payment processing, patient records and communication tools justify backup power and redundancy. A staff intranet may not.
Test your failure modes on purpose. Turn off the network, kill the process mid write, run the app on a nearly flat phone. You will learn more in an hour than in a month of reading logs.
Treat energy as a recurring line in the budget, not a surprise. If a solar and battery system pays for itself over time, model it like any other investment. Where it does not, plan the generator fuel.
And design transactions to be repeatable. Idempotent operations, durable queues and clear status states mean an interruption becomes a delay rather than a loss.
The opportunity inside the constraint
There is a more optimistic reading. Businesses that learn to operate through unreliable infrastructure develop skills that others lack: resilient design, efficient use of resources, careful thought about failure. Products built under these conditions can travel well, because they were never allowed to assume everything works.
None of this makes the constraint pleasant or fair. Reliable power is a public good, and no amount of clever engineering replaces it. But while the problem remains, builders have a choice between pretending it is not there and designing around it. The second approach produces better software and more honest budgets.
One question to ask this week
Look at your product and ask what happens in the middle of an outage. Not the beginning, not the end, the middle. If you do not know, find out before your customers do.