Privacy engineering is often narrated as a one-way export: a set of rules drafted in Brussels, refined in California, and shipped to the rest of the world to be adopted, translated, and complied with. The implicit story is that the centre invents and the periphery imports.
We work in Nairobi, and the view from here is different — and far more interesting. The constraints we operate under are real: intermittent connectivity, tighter budgets, infrastructure you cannot assume, and users whose threat models include risks a Silicon Valley product manager never has to consider. But constraints are not just obstacles. They are a design forcing function. They strip away the assumptions that let well-funded teams paper over weak privacy engineering with sheer compute and legal headcount.
This essay argues something we have seen repeatedly in client work: working under tighter resource constraints tends to produce sharper, more durable privacy solutions — not despite the limits, but because of them. Here are three patterns we have used that we believe travel well to any jurisdiction.
Constraint is a design discipline, not a disadvantage
There is a comfortable assumption baked into a lot of privacy tooling: that storage is cheap, bandwidth is abundant, and you can always collect now and decide later. Under those conditions, collect everything becomes the path of least resistance, and privacy becomes a thing you bolt on afterward to manage the liability you created.
Remove those assumptions and the incentives invert. When every megabyte synced over a metered connection has a cost, when every record stored is a record you are responsible for protecting, the cheapest engineering decision and the most private one start to converge. You stop asking what might we want this data for someday and start asking what is the least we need to deliver this feature. That question is the entire foundation of data minimisation, and scarcity asks it for you, relentlessly, on every feature.
This is why we treat resource constraints as a design discipline rather than a handicap. The same instinct that makes a system work on a patchy 3G connection in a rural county also makes it leak less, store less, and expose less. Good privacy and good engineering under constraint are frequently the same decision wearing two hats.
Three patterns that travel
1. Minimise at the edge, not in the warehouse
The dominant pattern in well-resourced systems is to haul raw data to a central store and reduce it later. The problem is that "later" rarely comes, and in the meantime you are sitting on a high-value target.
We default to the opposite: reduce, aggregate, and discard as close to the point of collection as possible, so the sensitive raw form never travels and never lands in a warehouse. Compute the aggregate on the device or at the edge; transmit the summary, not the source. This started as a bandwidth optimisation. It turned out to be one of the strongest privacy controls we deploy, because the record that never leaves the edge cannot be breached from the centre. It travels well precisely because it is jurisdiction-agnostic: it is sound whether your regulator is the GDPR, Kenya's Data Protection Act, or nothing at all.
2. Design for the offline-first, low-trust user
When you cannot assume a stable connection, you are forced to design systems that hold state locally and reconcile later. That architecture has a quiet privacy dividend: data that lives and is processed locally is data you are not centralising, not continuously exposing, and not obligated to guard in a honeypot.
It also forces honesty about trust. Many of the users we design for have well-founded reasons not to trust that a central server will handle their data benignly — they may be more exposed to surveillance, coercion, or data being turned against them than the median Western user. Designing for that user, rather than the comfortable one, produces systems that fail safe for everyone. The privacy floor you build for your most vulnerable user becomes the ceiling everyone else gets for free.
3. Make the privacy property legible and testable
Under constraint, you cannot afford privacy theatre — controls that look reassuring but cannot be verified. So we insist that a privacy property be stated as something you can actually test: a data flow you can diagram, a retention window you can enforce in code, a deletion you can prove happened. If you cannot demonstrate it with evidence, you do not get to claim it.
This is the same posture we bring to our research and our frameworks: a privacy guarantee that cannot be measured is a marketing claim, not an engineering one. Scarcity made us allergic to controls we could not verify, and that allergy turned out to be exactly right.
Why this matters beyond Nairobi
None of these patterns are uniquely African. That is the point. They are general-purpose privacy engineering that happens to be forced into focus by the conditions we work under. A team with unlimited budget can adopt every one of them — most simply never feel the pressure that makes them obvious.
The deeper lesson is about where good ideas come from. Treating privacy as something invented at the centre and consumed at the edge gets the direction of innovation exactly backwards. The edge, working under harder constraints and serving users with sharper threat models, is often where the most durable solutions are found first. The centre would do well to import a few.
At Reseni Labs, this is the conviction we build from: that privacy engineering done well under constraint is not a lesser version of the real thing — it is frequently the better one. We just had the good fortune to be forced to learn it early.
Reseni Labs is an independent research lab working at the intersection of privacy engineering, security research, and AI governance, based in Nairobi. We help teams prove their systems protect the people who use them, with evidence rather than assurances. If that is the kind of system you are building, get in touch.