Engineering Journal
We Never Bet a Product on One Vendor
Every system we build assumes something outside our control will eventually fail - a network connection, an API provider, a payment gateway, a single point of hardware supply. So we design for that failure upfront: multiple AI providers instead of one, offline-first sync instead of assumed connectivity, and vertical ownership of critical components instead of dependency on a single supplier. Resilience isn't an afterthought here. It's the architecture.
The question we ask before choosing infrastructure
Most technical decisions get made by asking "what's the best option available today?"
We ask a second question right after: "what happens to this product the day that option goes away, gets expensive, or goes down at 2am?"
If we don't have a good answer, we haven't finished the design.
No single AI provider gets to be a single point of failure
On VIGIL, our edge-AI perception system for UAVs, we didn't build around one model provider. We built a multi-provider AI model router spanning Anthropic, Alibaba's Qwen3-VL, Ollama, and vLLM - so a pricing change, a rate limit, an outage, or a policy shift at any single provider doesn't take the whole system down with it. The router picks the right model for the task and the right fallback when the first choice isn't available.
This isn't about hedging for its own sake. It's the same instinct that shows up in our engineering approach to open source: we don't want a client's product held hostage by a decision made in someone else's boardroom.
Offline isn't a fallback mode. It's the default assumption.
A shop assistant on StoreBase shouldn't lose a sale because the network dropped for thirty seconds. A field technician logging a job on SortAm shouldn't be blocked because signal is weak in a particular part of Port Harcourt or Lagos. A security guard verifying a visitor on MyEstate needs the gate to work even when the internet doesn't.
We learned this most directly rebuilding MediSeen HMS's sync architecture - moving away from a pure offline-first Redux pattern toward a backend-first, API-with-offline-queue approach using IndexedDB. The lesson wasn't "avoid offline." It was "design the queue and the conflict resolution deliberately, instead of hoping sync just works."
Connectivity in the markets we build for is real, but it isn't constant. Software that assumes otherwise breaks exactly when someone needs it most.
Vertical ownership, where it actually matters
Some dependencies are worth owning outright, not just diversifying against. On VIGIL FORGE, our drone design and manufacturing roadmap, that meant planning full vertical integration - airframe, propulsion, flight controllers on STM32H7, and battery pack manufacturing as a deliberate competitive advantage, not an outsourced afterthought.
The principle scales down as easily as it scales up. On SENTRI, our crypto wallet intelligence and AML compliance platform, we made the same call on data: full real provider integration across ETH, BTC, TRON, and SOL chains, rather than a single aggregator whose coverage gaps become our client's blind spots.
Resilience is a design decision, not a feature request
Nobody asks for "multi-provider failover" or "offline conflict resolution" in a first conversation about what they want built. They ask for a working POS, a working hospital system, a working drone. Resilience is the part of the job that doesn't show up in the demo - until the day it's the only thing that matters.
That's the same reason a SaaS production readiness audit exists as its own service, separate from the build itself: attack surface, tenant isolation, payment leakage, and deployment posture are exactly the things that look fine in a pitch deck and fail under real load, real abuse, and real single points of failure.
The takeaway
We don't build systems that assume the best case. We build systems that assume something will go wrong - a provider, a connection, a supplier - and make sure the product keeps working anyway.
That's not caution for its own sake. It's what "production-ready" actually means once you've watched enough systems fail at exactly the moment they couldn't afford to.
Mpaukwu Trading builds founder-led SaaS products, automation systems, and production-ready platforms for African businesses, including MediSeen HMS, SortAm, and StoreBase. Read more from the Engineering Journal or start a project.