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, and, eventually, for the people who live inside it to act on. 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 $1.99 to put a billboard in it, because a serious ambition doesn't have to be announced solemnly. But the ambition has two separate halves, and neither of them is finished. This essay is about both — what actually getting to "1:1" requires, why the half everyone shows you first is the easy one, and why the smallest, silliest thing we shipped turns out to be a working prototype of the hard one too.
KaNairo today — KICC, a matatu, a rentable billboard. The visible half, honestly labeled as v1.
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 ninety-nine, 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.
Legible isn't governable: the half that still doesn't exist anywhere
Even a perfect version of the institutional layer above — a Nairobi where every department's data is as live and cross-legible as Estonia's — solves only the reading problem. It makes the city legible to itself, department to department. It does nothing, on its own, with what a resident standing next to a burst pipe already knows and no sensor yet reports. A twin that only institutions can query is still, from the point of view of the roughly 3.5 million people who ride Nairobi's matatus every day, a one-way mirror: they're in it, it doesn't hear from them.
Legible is read-only. The missing half is write — a resident's tap becoming a real institution's ticket.
The idea that a legible model of a city has civic value by being playable isn't new — it's arguably where the whole genre started. Jay Forrester, the MIT systems theorist, published Urban Dynamics in 1969, a simulation of the feedback loops that drive urban growth and decay. Will Wright has said openly that encountering Forrester's book, while building a level editor for an earlier game, is what turned that editor into SimCity — and Wright has also been just as open that SimCity was conceived as a caricature of a city, not a model of a real one: useful for building intuition, disconnected from anyone's actual water pressure, by design. That distinction is the entire gap this section is about. A game can teach you how cities behave in general. It cannot tell a specific institution about a specific broken thing on a specific street, and be more than entertainment, unless someone deliberately wires it to something real.
People have wired pieces of this before — just never all the pieces, and never as one persistent, playable, city-scale system.
The report-to-institution half doesn't need a 3D layer at all, and Kenya proved that first. Ushahidi — Swahili for "testimony" — started as a blog post: on 3 January 2008, during the post-election violence, Ory Okolloh asked whether any developers could build a way to map reports of what was happening. Erik Hersman, Juliana Rotich, and David Kobia had it live six days later. It became crowdsourced crisis-mapping software used far past Kenya's own crisis — the platform's own figures put it at over 125,000 deployments across more than 160 countries by 2017, from roughly 40,000 reports mapping Haiti's 2010 earthquake to election-monitoring deployments back home. In Kenya's own 2013 election, one study found three-quarters of the people who filed a report said someone had actually responded to it — self-reported, not independently audited, but a real signal that reporting-to-response can work, at scale, over SMS, with no rendering of anything.
Nairobi's own water utility is the more specific precedent, because it's the same city and, in a sense, the same sector this essay already talks about. MajiVoice, built out from 2012 with World Bank support for the Nairobi City Water and Sewerage Company, lets a resident report a problem — a leak, a billing error, a dry tap — by SMS, USSD, or web, routed automatically to the department actually responsible, with escalation if it stalls. Independent evaluation found complaint volumes rose roughly tenfold once the integrated system existed, and that about six in ten complainants across channels felt their complaint had actually been taken seriously — a low bar stated honestly, and still evidence the loop works once someone builds it.
The same pattern shows up outside Kenya. The UK's FixMyStreet, running since 2007, passed 1.1 million citizen reports by 2017 — about half of them potholes — each geolocated and routed to the responsible council; its operator, mySociety, is candid that a report only shows as "fixed" once someone manually marks it, so the published resolution numbers understate reality rather than overstating it, which is the right kind of imprecise to be. In the US, SeeClickFix, started in New Haven in 2008 after its founder got nowhere reporting graffiti through the city's own channels, grew past a million registered users and several million reports, with fix rates self-reported around 90% at various points before its 2019 acquisition by CivicPlus; Boston built its own citizen-reporting app as one of the first projects out of its Office of New Urban Mechanics. None of these render anything. They don't need to. The loop — resident flags something, it lands in a queue a real department works from, someone closes it — has been proven repeatedly, for close to two decades, without a single polygon.
The playable-co-design half has also been proven, separately, and it has a Kenyan example of its own. UN-Habitat's "Block by Block" program, running since 2012 with Mojang and Microsoft, has residents redesign an actual public space inside Minecraft — walking through a real proposed park or market before it exists, moving things, arguing about placement — and then hands the design to professional architects to develop and, in many cases, physically build, sometimes with the same residents doing some of the construction. UN-Habitat's own figures put the program at 55 countries and more than 3 million people reached through the process, including a community space co-designed for Kalobeyei, the refugee settlement in Turkana County, Kenya. It's the closest existing thing to "residents build the city in a game and it gets built for real" — and it's explicitly episodic: a workshop, a design sprint, a handoff to construction, not a live, persistent, always-on twin a resident can return to next month to flag something new.
The persistent, always-on version exists too, in early form, and the honest academic literature on it is worth taking seriously precisely because it isn't triumphant. Helsinki's SmartKalasatama and Rotterdam's urban digital twin both let residents view a live 3D model of their own neighborhood and leave feedback on it — real systems, not demos. Peer-reviewed case studies of both have independently landed on the same finding, using nearly the same phrase: participation on these platforms is real but "limited by design" — planners decide in advance what can be commented on and what can't, and a small, non-representative slice of residents actually engages, for reasons ranging from distrust to language barriers to simply not knowing the platform exists. That's not a knock on the projects. It's an honest accounting of where the frontier currently sits, which is short of an actual two-way governance loop.
And someone has already written down the idea this essay is building toward, without building it. In 2019, the civic technologist Devin Balkind argued in the Gotham Gazette that New York should build SimCity-style citizen interfaces on top of its own open government data — interactive maps, participatory-budgeting sliders, prompts at the moments decisions are actually being made. It's a good essay. It's also, years later, still an essay — an opinion piece proposing the synthesis, not a shipped system.
Put those threads together and the honest gap is narrow and specific. Reporting-to-institution works, with no game layer, at real scale — Ushahidi and MajiVoice prove it inside Kenya specifically. Game-layer co-design that produces real construction works, episodically — Block by Block proves it, including once inside Kenya. Persistent 3D participation exists, but is deliberately bounded — Helsinki and Rotterdam prove that much, and are honest that it's not more. And the full synthesis — a persistent, playable, live 1:1 city twin, where flagging something broken is the ordinary act of playing with the model and it produces a real ticket in a real institution's real queue — has been proposed in an op-ed and not, as far as this research turned up, actually built and shipped by anyone, anywhere, at city scale. That's not a claim that nobody has thought of it. Balkind thought of it. Nairobi invented half of it in 2008. It's a claim that nobody has closed the loop, persistently, at the scale of a whole city — and that's the second half of "1:1" this project doesn't have yet either.
Why the write side doesn't need a new backend
The reason this isn't just another ambitious civic-tech pitch is that the queue at the other end of that wire, in Nairobi's case, mostly doesn't need to be invented. It already exists, sector by sector, inside the institutions Flux already builds for — which is a different claim from saying the wiring itself already exists, because it doesn't yet. It's a claim about what kind of problem is actually left.
AccessWASH already runs field-operations queues for four Nairobi-area water utilities — mobile meter reading, service requests, dispatch, all in production today. A resident tapping a leaking pipe on the twin, in the version of this that doesn't exist yet, wouldn't require a new system to receive that report. It would require a new front door onto a system that already dispatches real technicians against real service requests. MajiVoice already proved, at an actual Nairobi water utility, that the "resident reports, utility routes it internally" half of that loop works without any 3D layer at all — which is the argument for building the map on top of infrastructure already proven underneath it, instead of inventing a second, parallel one.
The same shape holds in the civic sector. Democracy Is Infrastructure describes a constituency office running its casework — bursary requests, CDF petitions, constituent complaints — on WhatsApp groups and a shared spreadsheet nobody updates consistently; BungeConnect exists to give that office a real case-management system instead. A resident tapping a stalled bursary application or an unresolved ward complaint on a Nairobi twin, in the version that doesn't exist yet, would be the same kind of fact BungeConnect already structures as a case — arriving as a located point on a real map instead of one more message in a thread of hundreds nobody has time to search.
And the health sector is standing at the same door from the opposite direction. The Last Mile of Care: What Kenya's Community Health Workers Are Missing describes Kenya's 100,000-plus community health workers collecting exactly the kind of household-level fact — a symptom cluster, a broken clinic tap, a stalled referral — that currently dies on paper before it reaches anyone who can act on it. A CHW's field note and a resident's own report of the same problem are the same fact, arriving from two directions; a twin that can eventually receive both isn't proposing new data. It's proposing one door for data that's already being generated and currently going nowhere.
None of this is built. Say that plainly, because the temptation with an essay like this is to let the roadmap read like a feature list. It isn't one yet. What's true is narrower and, we think, more honest: the hard part of this — proving, sector by sector, that African institutions can run on a real operating layer instead of paper and WhatsApp — is the part Flux has spent every essay before this one arguing for and building toward. Wiring a citizen's tap on a 3D map into a queue that already exists is a front-end problem sitting on top of years of already-underway backend work, not a new institution-building project starting from zero. That's a meaningfully smaller gap than "nobody has ever tried this" — and it's also not "this already works." It's the actual, specific, unglamorous distance still left to cover.
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 needs that operating layer on both sides of the glass. On the institutional side: 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. On the resident side: the fact that a specific pipe on a specific street is leaking, reported by the person standing next to it, arriving at the utility not as a WhatsApp message lost in a thread of hundreds but as a structured case in the same queue AccessWASH's field technicians already work from — or a bursary application that's stalled, arriving at a constituency office as a case BungeConnect can actually track, not a rumor passed between three phone calls. Both are the same problem stated twice: a fact, sourced once, immediately usable by everyone who needs it — 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 both halves, honestly labeled as a beginning. The ledger underneath it — on the institutional side and, eventually, the resident side — where every fact is sourced and nothing is invented, is the part we're actually building toward. It's the part that turns "looks like Nairobi" into "is Nairobi, and answers to Nairobi," which is the whole ambition.
Here's what the billboard actually is, underneath the joke: the smallest possible working version of "you can act on the twin and the twin visibly changes." You pay $1.99, you tell it what your billboard should say, we manually check nothing ugly goes up, and a sign appears exactly where you pointed. That's the entire mechanic of the write side that's still missing everywhere else — pointing at a location, describing something, and the model changing in response — with the stakes turned all the way down. Nobody's water pressure depends on your billboard copy. The real version of that same mechanic is aimed at something that matters: you tap the spot, you describe what's actually broken, and instead of a sign, a ticket appears in a queue a real institution already works from. Nairobi's own water utility already proved the reporting half of that works with nothing fancier than SMS. Nairobi's own countrymen proved the reporting-to-response half of it at national scale in 2008, before "civic tech" was a category anyone funded. Nobody, anywhere, has proved the whole loop yet — persistent, playable, wired straight through to a real institution's real queue, at the scale of an entire city. That's the part v1 doesn't do. It's the part every version after v1 is actually for.
Same mechanic, different stakes: a sign you paid for, versus a ticket nobody's built yet.
So: go rent a billboard. It's a genuinely good joke and the $1.99 is genuinely real — and now you know exactly what kind of joke it is: the practice round for the feature that was the point all along. If "a city with a real digital twin, that residents can actually act on and institutions actually answer" sounds like something worth building — not just rendering, not just imagining — that's the conversation, and the years of work, we're actually signing up for.
