Why “boring” stacks quietly win
Let’s be honest.
The internet will make you feel as if you’re not on microservices, Kubernetes, and ten different managed services, you’re already behind.
But when you’re deploying from a place where power can disappear mid-deploy and users are on cheap Android phones, “boring” suddenly looks brilliant.
A monolith with a simple deployment pipeline is easier to revive after NEPA hits than a fragile mesh of services that all need to be healthy at once.
Your users don’t care how modern your stack looks on a conference slide.
They care that your app opens on 3G… and doesn’t crash when their battery is at 9%.
Monoliths: your friend in chaotic environments
Many of us start with monoliths because we don’t know any better.
Years later, we realize they were the sanest choice all along.
A monolith means:
One codebase to reason about when something breaks at 11:47 p.m.
One deploy step, not five services while the generator is groaning.
Simpler logging and debugging — SSH in, check logs, fix, redeploy.
In places where power is unreliable, every extra moving part is just another thing waiting to die at the worst time.
For early-stage products, monoliths give you:
Faster iteration — change a feature, test, ship.
Less infrastructure brain-load — no part-time SRE role just to release a signup flow.
If you’re still chasing product–market fit, the last thing you need is debugging cross-service timeouts while users are begging for a working password reset.
NEPA realities: designing for failure
Power cuts don’t care about your sprint plan.
They introduce invisible requirements most architecture diagrams never mention:
Your dev environment must survive sudden shutdowns without corrupting everything.
Your deployment process must be resumable — you should know how to roll forward or roll back when the lights come back.
Your app must tolerate flaky networks on both server and client.
That shapes your stack:
Databases
Pick something mature and boring, with solid backups and tooling you understand.
Frameworks
Use ones with great docs and big communities. You don’t want to be begging for help on Discord while your inverter is beeping.
Background jobs & queues
Start simple. A single worker or cron-style system beats a complex distributed queue that needs babysitting.
Design as if NEPA will interrupt you at the worst possible moment. You’ll naturally choose stacks that recover cleanly.
Real users don’t live in data centers
It’s easy to design for the laptop in front of you instead of the humans using your product.
In Lagos, you’re often building for:
Low-end Android phones with limited RAM
People buying small data bundles
Users in buses, markets, offices, and homes where the network jumps from “okay” to “are we online?” in seconds
Your stack decisions reach all the way to them:
Heavy SPAs with massive bundles can feel broken on cheap phones. Sometimes server-rendered pages with light JavaScript are kinder.
Over-architected backends add latency users can feel on shaky networks.
Some cloud services are hard to pay for from Nigeria — and rewrites later are painful.
So don’t ask, “What’s the coolest stack?”
Ask:
What keeps response times low on bad networks?
What’s affordable and predictable to host here?
What can my future teammates understand and maintain?
A pragmatic playbook for choosing your stack
If you’re staring at VS Code wondering what to use, try this:
- Start with constraints, not hype
List your limits: power, budget, team skill, hosting, payments, user devices.
Ignore them and you’re planning a future rewrite.
- Default to a monolith
One repo. One deploy. One database.
Design clean layers so you can split later if needed.
- Pick tools you can debug half-asleep
If you can’t explain how to fix it on a midnight call, it’s too complex right now.
- Optimize for the worst connection
Test on bad mobile networks.
Avoid huge bundles, chatty services, and unnecessary round trips.
- Think about future you (and future devs)
In two years, will you still understand this setup?
Can you ship a fix in one evening after a break?
- Add complexity only when pain forces you to
Introduce queues, caches, services, and CDNs when metrics demand it — not because a blog said so.
When to move beyond the monolith
Sometimes the monolith really does start to groan:
Teams grow and deploys collide
One part of the system scales very differently
Releases become risky and slow
When that happens, treat microservices like surgery, not fashion:
Split one well-defined part first
Keep logs, metrics, and alerts simple
Make sure the team understands the cost and responsibility
Every extra service makes your system more brittle — especially in environments where power cuts and network hiccups already exist to humble you.
If you’re building from Lagos, Abuja, Nairobi, Accra — or anywhere that doesn’t look like a glossy Silicon Valley data center — your reality is different.
And your stack should reflect that.
Your superpower isn’t chasing trends.
It’s choosing tech that keeps serving real users when the power blinks, the network stutters, and life gets messy.
Monoliths, NEPA, and real humans aren’t enemies.
They’re the constraints that push you toward a stack that actually works.
