Here is the goal, stated plainly, because it's easy to miss under the joke: we want to build Nairobi a real, 1:1 digital twin. Not a screenshot. An actual live, queryable model of the city — its streets, its buildings, its traffic, its water and power and drainage — that's accurate enough to plan against, not just look at. What we shipped this month is the first, smallest, most visible piece of that: a real, explorable 3D model of Nairobi with actual streets and actual buildings and KICC where KICC actually is. Then we let people pay a dollar to put a billboard in it, because a serious ambition doesn't have to be announced solemnly. But the ambition is serious, and this essay is about what actually getting to "1:1" requires — which is almost never the part people show you first.
The half everyone shows you
Say "digital twin" to most people and they picture a screen: a rotating 3D city, maybe some glowing dots, a dashboard with numbers ticking up in a font that looks vaguely like a spaceship's. That's the half that gets funded, demoed at conferences, and screenshotted for pitch decks. It's also a drift from where the term came from. NASA's Michael Grieves proposed the concept in 2002 — not as a rendering, but as a virtual model kept in continuous, live sync with one specific physical object, so engineers could ask it questions about that object's real condition; the name "digital twin" itself wasn't coined until 2010, by NASA's John Vickers. A spacecraft twin was worthless the moment its telemetry went stale. A city twin is no different — it's worthless the moment the data stops being live, whatever the rendering looks like.
A pretty model of a city tells you what the city looks like. It does not tell you which water main is about to fail, which junction needs a second traffic light before the next rains flood it, or which building permit application contradicts the zoning map three departments haven't reconciled with each other. A model that actually answers those questions — a real twin, not a likeness — has nothing to do with how good the rendering is. It has everything to do with whether the data underneath is real, current, and connected to something that can act on it.
Our Nairobi, today, isn't there yet. It's OpenStreetMap data, procedurally extended past the edges of what's actually surveyed, driving a Three.js scene that looks convincing at a glance and falls apart the moment you ask it a real question — "how many matatus pass through this junction at 6pm" or "will this drainage channel hold the next long rains." It doesn't know. Closing that gap, honestly and in order, is the actual roadmap. Calling today's version "done" would be the dishonest move, not building it in public while it's obviously incomplete.
What closing that gap actually required, somewhere else
Estonia is the case everyone in this space eventually points to, and it's worth being precise about why, because the usual telling ("small country, digital everything, e-Residency, cool") skips the part that matters — the part that's the actual template for getting to 1:1.
Estonia's low-legacy starting condition after regaining independence in 1991 gets credited for a lot, but the actual data-exchange system — X-Road — wasn't a product of that early moment. It started as a pilot in 1998, was first shown publicly in 2000, and launched properly in 2001 under Estonia's Information System Authority. And it wasn't built the way most "digitize government" efforts are: a scanned form instead of a paper one, one database per department. It was pushed toward a decentralized design in part because of a 1996 scandal, in which a government contractor quietly compiled a "superdatabase" of citizens' personal records pulled from multiple state systems and tried to sell access to it. Estonia's answer wasn't a bigger, better-guarded central database. It was to never build one: X-Road lets each institution keep its own authoritative records and answer queries from other institutions directly, peer to peer, with every query logged. Today it connects more than 450 public and private organizations and carries over 3,000 digital services. Every Estonian can log into the state portal with their digital ID and see, via a tool called the Data Tracker (live since 2017), exactly who has queried their personal records and why — unauthorized access is a criminal offense, and it has been prosecuted.
That's the part that's hardest to copy, and the part a real twin actually depends on: Estonia didn't digitize documents. They digitized the relationships between institutions, under what they call the "once-only" principle — a citizen's address, once recorded anywhere in government, should never have to be typed into a form again, because a birth registration should be able to instantly update the tax system's dependent-count and the health system's newborn registry, being facts about the same event rather than five separate paperwork processes that happen to describe it. A 1:1 digital twin of a city, in the sense that actually pays off, isn't a 3D rendering that happens to be detailed. It's a live, queryable, permissioned map of which institutional facts depend on which other institutional facts — with the rendering as a legible window onto it, not a substitute for it.
Once that layer exists, the pretty visualization stops being a demo and starts being trustworthy. A 3D flood model of Nairobi's drainage basins means something once the sensor data feeding it is real, current, and the same data three different departments are already using to make decisions — not a separately-maintained showcase dataset that drifts out of sync with reality within a quarter. That's what 1:1 actually means: not that it looks right, but that you could act on it and be right.
Why we're building the visible layer first
None of this means starting with the render was a mistake — it means being honest that the render is the beginning, not the finish line. A legible, explorable model of the city is one of the best interfaces you can eventually put in front of both officials and residents — Nairobi's actual traffic-light phasing, actual matatu route load, actual water pressure by ward, understood at a glance instead of buried in a spreadsheet nobody outside one department ever opens. We're building that interface first, in public, specifically so the harder, invisible work underneath it — the equivalent of Estonia's X-Road, sector by sector — has something real to plug into as it gets built, instead of shipping years of institutional-data infrastructure and only then finding out nobody wanted to look at it.
Nairobi has already had a small, real preview of what that looks like, and it's worth naming: Digital Matatus, a 2014 project run by MIT, Columbia, the University of Nairobi and the design studio GroupShot. Nairobi's matatu network — the minibuses roughly 3.5 million people ride every day — had never been formally mapped; drivers and riders navigated it entirely on memorized institutional knowledge. Student teams rode more than 130 routes with GPS-enabled phones, logged over 3,000 stops, and published the result as open GTFS transit data — the same format Google Maps and transit apps use everywhere else. It's now a routable layer in Google Maps, and it became a reference model other African cities have followed for mapping their own informal transit. That's the pattern exactly: not a rendering of matatus, a real, open, queryable dataset of where they actually go — built once, useful to everyone downstream, from riders to city planners.
The stakes for doing more of this aren't hypothetical. The 2024 long rains flooded Nairobi's informal settlements — Mathare, Kibera, Mukuru — worst of all, part of flooding across Kenya that the Kenya Red Cross put at close to 300 deaths nationwide; investigations afterward pointed to construction on riparian land and drainage systems that were clogged, undersized, or simply never extended as the city grew past them. Nairobi flooded again in March 2026, the worst rains since 2024. The county's response, the roughly KSh 50 billion Nairobi River Regeneration Programme, is explicitly about reclaiming riparian land so the rivers have room to flow — which is exactly the kind of decision a real drainage-and-rainfall model, tied to live sensor data instead of an old engineering study, would make easier to plan and defend before the next long rains, not after.
There's also a narrower, more honest reason we built it backwards: it's an unusually honest way to find out whether people care right now, before we spend years on it. A free "sign up for updates on civic digital infrastructure" form tells you who's polite. A dollar, spent on a joke billboard in a real model of a real city, tells you who's actually willing to put something — however small — behind the idea that their city having a real digital model of itself is worth paying attention to. It's not market research we're proud of methodologically. It's market research that's honest about its own incentives, which is more than most surveys can say.
What this has to do with what we actually do
Flux's argument, the one underneath every product we ship, is that African institutions — water utilities, county governments, regulators, hospitals — don't mostly lack technology in the abstract. They lack the operating layer: the thing that makes a fact recorded in one place immediately, verifiably usable in every other place that fact matters, the same "once-only" logic that lets an Estonian birth registration update three other systems without anyone re-typing anything. Most software sold into these institutions today is a nicer form for the same paperwork. It digitizes the document. It doesn't digitize the relationship between the document and the fifteen other things that are true because that document exists.
A real, 1:1 Nairobi digital twin — matatu routes optimized against real ridership data the way Digital Matatus already started, drainage modeled against real rainfall and real sensor data instead of a decade-old engineering study, building permits checked against a zoning map that's actually current — is not, in the end, a rendering problem. It's an operating-layer problem, sector by sector, institution by institution, which is the only kind of problem we're actually built to solve. The render you can explore today is the beginning of that, honestly labeled as a beginning. The ledger underneath it, the one where every fact is sourced and nothing is invented, is the part we're actually building toward — and it's the part that turns "looks like Nairobi" into "is Nairobi," which is the whole ambition.
So: go rent a billboard. It's a genuinely good joke and the dollar is genuinely real. But if "a city with a real digital twin" sounded like something worth actually building — not just rendering — that's the conversation, and the years of work, we're actually signing up for.
