Practical AI software from Uganda: How we build

Start with the operating problem

AI can produce an impressive demonstration in minutes. Dependable software is harder. It has to fit the work around the model: how a customer asks for help, how a merchant confirms an order, how a rider receives a delivery, and how an operator responds when the expected journey breaks down.

That is why Vlaux begins with the person doing the work rather than the technology. Before choosing a model or automation, we map the decisions, information, handoffs, and failure points that shape the outcome.

• Who needs to act, and what do they need to know first?
• Which decision can software assist, and which must remain with a person?
• What information is trustworthy enough to use?
• What does failure look like, and how can the team recover safely?
• Who should approve or review an important action?

What practical AI software from Uganda must account for

Local context is not a decorative layer added after the product is built. It changes the product requirements. In the systems we are developing, we test whether the customer channel is familiar, whether a mobile workflow stays focused while someone is moving, whether payment and delivery choices match the operating model, and whether staff can understand the next step without specialist training.

We avoid treating one behaviour as true for every person in Uganda. Instead, each product begins with evidence from its own users and operation. CheapCheap, for example, is a Gulu retail operation with WhatsApp ordering and cash on delivery as part of its current model. Those choices are specific product decisions, not assumptions about an entire country.

Build a connected workflow, not an AI demonstration

A model is only one component of a useful system. The surrounding product still needs a clear interface, validated inputs, controlled state changes, useful records, and a recovery path. Without those parts, an intelligent response can create more uncertainty than it removes.

Connected product design follows the work from beginning to end. A customer request should become information a merchant can act on. A prepared order should become a delivery opportunity a rider can understand. An exception should become something an authorised operator can see and resolve. AI can assist at several points, but the operating loop keeps everyone working from the same journey.

Responsible AI keeps people in control

Practical AI can interpret a request, prepare a draft response, summarise activity, or highlight an exception. It should not quietly take ownership of prices, orders, money, dispatch, customer commitments, or access to sensitive information.

For those actions, the product needs boundaries. Inputs must be checked. Important changes need authorised workflows. Teams need to know what happened and, where appropriate, who approved it. If the system is uncertain, it should make that uncertainty visible and create a route to human review instead of inventing confidence.

Learn through products in operation

CheapCheap and PikiPiki OS help us test this approach against real commerce and logistics work. CheapCheap gives us an operating context for ordering, fulfilment, cash on delivery, and the handoff to delivery. PikiPiki OS is in active development as a shared logistics loop for customer, merchant, rider, and operator experiences.

Working close to the operation exposes the details that a specification can miss: where a status is ambiguous, where two people need different views of the same event, or where a simple manual checkpoint is safer than another layer of automation. Those lessons improve both the current product and the reusable foundations beneath it.

Useful software should earn trust over time

A launch is not proof that a product works. Teams need to observe how it behaves, learn from support questions, review exceptions, and improve the places where people hesitate or work around the system. Reliability grows through that cycle.

This is our standard for practical AI software from Uganda: start with real work, design for the people and conditions around it, keep consequential actions accountable, and measure the result by whether the operation becomes easier to understand and run.