Building the Infrastructure People Can Trust

From your experience building for users in Abidjan, what shapes how people perceive digital products there? What makes a product feel reliable, credible or worth using?

I think the first assumption I would challenge is that people simply do not trust digital services or products.

Sometimes, we talk about trust as though it is something we are entitled to as builders, and users are somehow reluctant to give it to us. But when you consider the environment people operate in, many of their concerns are entirely rational.

I have worked on products serving multiple markets across Africa, particularly in commerce and digital services. One thing you quickly learn is that users do not evaluate your product based solely on the interface. They bring their previous experiences with other products into every new interaction.

Perhaps they have previously paid for something online and had a transaction fail without knowing whether the money was actually deducted. Maybe they ordered something and had no way of understanding the status of that order.

That is why I think reliability is much broader than uptime.

Take an e-commerce product. Imagine I select a product, proceed to checkout, make my payment, and then nothing happens for about ten seconds. Technically, as engineers, ten seconds may not sound catastrophic. From the customer’s perspective, however, those ten seconds can create a series of very serious questions:

A performance problem has suddenly become a trust problem. That is something I think engineers need to understand.

Users do not categorise problems the way we do. We might describe it as a network timeout, but the customer does not care that it was a timeout. Their interpretation is much simpler: “I don’t trust this service with my money.”

So when I think about what makes a digital product credible, I think less about perfection and more about consistency and predictability. When something happens in my product, I need to tell the user why it happened and what they can do next. If something fails, do I understand what I should do next? And if I need help, can I actually reach someone who can help me?

How do connectivity, device capabilities and network conditions influence the technical decisions you make when building for these users?

One principle I try to keep in mind is that we should build for the environment our users actually have, not the environment we wish they had.

As engineers, there is a trap we can easily fall into. We build on relatively powerful computers, test with good Wi-Fi, and look at the product on recent smartphones or large desktop monitors. Everything feels fast and responsive. But when you ship that same application to someone using a different device, relying on mobile data and dealing with an unstable connection, the experience can become completely different.

Those realities therefore need to influence the architecture from the beginning, rather than becoming an optimisation we think about months later when the product is already in production.

For example, I care about how much we are asking the user to download. Do we really need that huge image? Can certain elements load progressively? Can the most important action remain accessible even if another part of the page has not loaded yet?

But I think it goes much further than frontend performance. Let’s assume a customer initiates a payment and the connection disappears immediately. That is a very important scenario that engineers should be designing for. What happens when the customer reconnects? Does the customer have to restart the entire process? Could they accidentally pay twice?

Then there are architectural questions created by the reality of the user’s environment and our dependence on third-party services. We cannot control all of those variables. Generally, I do not like designing systems around the assumption that every dependency will always respond correctly and immediately.

Because ultimately, at the end of all that architecture, there is a person trying to accomplish something through your application.

What happens to the customer experience when problems such as slow performance, failed transactions or downtime occur?

I think we need to distinguish between failure and uncertainty because they are not exactly the same problem.

Every digital system will eventually fail somewhere. A server can go down, a network request can time out, or a third-party service can become unavailable. You cannot realistically promise that none of those things will ever happen. What you can control much more effectively is what the customer experiences when they do.

From my experience, uncertainty can sometimes be more damaging than the failure itself. Payments are probably the clearest example.

Think about the customer’s position at that moment. They may not even know whether the company will be able to resolve the issue. That is no longer just an engineering incident. It has become a customer support problem, a financial problem and potentially a reputational problem.

That is why, when I work on these kinds of systems, I care a lot about states. A transaction is not always simply successful or failed.

The product experience needs to reflect that reality. The same principle applies to downtime and performance. If something is going to take time, tell the user. If something has failed but the system is retrying it, tell them. If their action has been saved and will be processed later, tell them that too.

How should engineers approach architecture and system design when they know the conditions their product operates in are not always predictable?

The biggest mindset shift for me is to stop treating failure as an exceptional scenario. Failure is part of the system. The network will eventually fail. A user will eventually close the application in the middle of an operation. A third-party provider will eventually behave unexpectedly.

So when I think about architecture, I do not only ask, “How does this work?” I also ask, “How does this fail?” That is a very different engineering question.

Architecture becomes interesting when you start asking uncomfortable questions.

Now you are thinking about concepts such as idempotency, reconciliation, transaction states, monitoring and observability. But engineers also need to resist the temptation to over-engineer. Resilience does not mean putting 20 or 30 technologies into your architecture. You need to understand what can realistically fail, what the business impact of that failure would be, and then design the appropriate protection around it.

If a blog being unavailable for five minutes and a payment system losing track of a customer’s transaction are both technically failures, they clearly do not deserve the same architectural response.

So my philosophy is quite simple: architecture should absorb uncertainty so the user does not have to. The customer should not need to understand that one of our providers is experiencing an issue. As much as reasonably possible, the system should detect the problem, recover from it, give the team visibility into what happened and provide the customer with a clear experience.

Technical reliability vs. user experience: how can a team tell when a product is technically functioning but still failing users?

This is something engineering teams need to be particularly careful about because our tools can sometimes give us a false sense of success.

Imagine I open the monitoring dashboard and everything looks healthy. The server is running, CPU and database utilisation look fine, the error rate is low, and the API is returning successful responses. From an infrastructure perspective, I can say that everything is working. But that does not necessarily mean the product is working for the customer.

Maybe the checkout endpoint is returning a successful response, but the customer does not understand what they are supposed to do next. Maybe the system communicates the transaction clearly, but confirmation takes so long that the customer tries again. The system works, but the experience does not.

That is one reason I am interested in connecting engineering data with product and business data. I want to know the latency and error rate, but I also want to know where people are abandoning a flow, how many people are retrying, what customers are complaining about and which actions require manual intervention from our team. Those signals can reveal problems that infrastructure monitoring alone will never show.

Customer support, in particular, can be an incredibly valuable source of engineering insight. If 10 or 20 customers contact support about the same confusing problem, that is not necessarily 20 separate support problems. It may be one product or architectural problem manifesting itself 20 times.

The cost of getting infrastructure wrong: what are the consequences when teams underestimate the technical realities of the market they are building for?

The first mistake is assuming that the cost of poor infrastructure is simply downtime. The real cost spreads across the entire business.

You can lose money. You create additional support requests. The operations team begins building manual workarounds. Engineers spend their time firefighting instead of building. Eventually, you can lose customers themselves.

But there is another cost that is much harder to quantify: lost confidence. That becomes particularly significant when the failure happens during a critical interaction.