A lot of software is built somewhere with fast fibre, the newest phones and a single tap-to-pay habit, and then shipped everywhere else as if those things were universal. They aren't. Daily life in much of South Africa runs on careful data, a phone that's a couple of years old, signal that comes and goes, and a comfortable mix of cash and card. None of that is a problem to be fixed. It's the actual world the software has to work in.
We don't treat those facts as edge cases to patch at the end. They're the brief. Starting from them changes what you build, not just how you talk about it.
It means we care about how much a screen costs to load, because someone is paying for those megabytes. It means a feature has to survive the connection dropping halfway through. And it means payment can't assume one method, or one habit.
Designing for the conditions people have isn't a limitation. It's the difference between software that works in a demo and software that works on a Tuesday.
We work from the KwaZulu-Natal coast, and that's not a flag to wave — it's just useful. The realities we're designing for are the ones we live in. We're not interpreting a market through a research deck; we're building for the same conditions we use our own phones in. When something is annoying, we feel it too, which is the most reliable bug report there is.
RedHailer is one product shaped this way. The approach is meant to outlast it. Whatever we build next will start from the same place: real phones, real budgets, real connections, real ways of paying. If that sounds unglamorous, good. The unglamorous parts are usually the ones that decide whether a thing is actually useful.
If you're building in the same conditions, or you want to put what we've made to work, we'd like to hear from you.
— The Qwezy Digitals team