Most software that reaches Rwanda was designed somewhere else, for someone else, and then translated. It arrives assuming a fast connection, an unlimited data plan, a credit card, and a laptop. Every one of those assumptions costs somebody here something, and the cost is usually invisible to the people who made the software.
We started AYA Informatica RW because we think the more interesting problem is the other direction: building from here, for how things actually work, and finding out that the constraints make the product better rather than worse.
The phone is the computer
In much of the world, mobile is the second screen. Here it is the only one. People meet the internet on a phone, buy on a phone, run a business on a phone.
That is not a smaller version of the desktop problem. It changes what good looks like. A checkout flow that takes four screens on a laptop is four opportunities to lose someone on a bus. An image-heavy page that loads comfortably on office wifi is a real cost to a person paying for each megabyte. An app that assumes a stable connection breaks the moment it meets a real one.
Designing mobile-first is not a style choice. It is the difference between software that gets used and software that gets abandoned on the second try.
Data is not free, and neither is trust
Two constraints shape almost everything we build.
The first is that bandwidth costs money that people notice. So we care about payload sizes in a way that feels excessive to teams building for markets where data is effectively unlimited. Fewer round trips. Smaller images. Pages that work before all the JavaScript has arrived.
The second is harder. In a market where most trade still happens through personal networks — a friend of a friend, a WhatsApp group, someone your cousin vouches for — a stranger on the internet starts from behind. Trust is not a feature you add at the end. It is the thing the product has to earn before anything else works, and it is earned through details: showing who you are dealing with, making the terms obvious, never surprising someone with a cost.
Software that ignores this gets built, launched, and quietly unused.
Language is not a translation layer
Rwanda works in Kinyarwanda, French and English, and people move between them constantly. Treating one as the real language and the others as translations produces something that technically supports three languages and feels native in one.
We publish this site in all three. We are also honest that the Kinyarwanda is not yet where we want it — machine translation gets you a draft, not a voice, and we would rather say so than pretend otherwise while a native speaker reads it properly.
Getting this right is not charity. Kinyarwanda-language search is almost entirely uncontested, which means the effort nobody is spending is available to whoever spends it.
Constraints as a design brief
The pattern in all of this: what looks like a limitation is usually a brief.
Build for a phone on a patchy connection and you end up with something fast enough to be pleasant on a good one. Build for a market where trust has to be earned and you end up with a product that is honest by construction. Build for three languages and you stop writing copy that only makes sense in one.
None of this is unique to Africa. It is just that here you cannot skip it.
What we are doing about it
RAY Markets is the first thing we have shipped against these ideas — a marketplace for buying and selling in Rwanda, built mobile-first, free to list on, and designed so that both sides of a trade can see who they are dealing with. It is live, people are using it, and it is teaching us where the theory was wrong.
Humura, a mental wellness platform, is next. Different problem, same constraints.
We are a small team in Kigali, and we are not going to claim we have this figured out. But we would rather build the thing that fits than import the thing that does not.
If you are building something here and any of this sounds familiar, we would genuinely like to hear from you.