July 01, 2024 · Cities

Smart cities are easy to sell. Who are they actually for?

Dimple Paratey
Dimple Paratey
Chief Marketing Officer
Smart cities are easy to sell. Who are they actually for?

There's a man I pass most mornings on the school run. He gets around our high street in a wheelchair, and watching him do it is a daily reminder that the city was designed by people who never had to. The dropped kerb that isn't quite dropped. The "accessible" route that adds twenty minutes. The pavement café that's colonised the only flat bit of path.

I think about him whenever I'm shown a "smart city" pitch, because he is almost never in it. The slides are full of glowing dashboards and sensors and traffic flowing like water, and somewhere in there, unspoken, is a fantasy of a citizen who is young, able-bodied, owns a smartphone, and has nothing to hide. He is not that citizen. Nor, on a bad day, am I.

"Smart city" isn't really a technology. It's a shopping basket — sensors, dashboards, traffic systems, and, far too often, facial recognition — sold to councils as one tidy bundle. Some of what's in the basket would genuinely make life better for the man on the high street. Some of it would make him a data point whether he likes it or not. The whole job is telling those apart before someone signs a fifteen-year contract.

The stuff that genuinely helps real people

Let me start with what I'd happily see my own council buy, because it's worth saying that some of this is properly good.

Traffic signals are the obvious one. Most of them were timed decades ago using rules of thumb, and they've been faithfully causing jams ever since. Adjusting them to what's actually on the road eases congestion and clears the air a bit — and, crucially, it works perfectly well without knowing who's sitting in any of the cars. That distinction matters more than anything else in this piece, so hold onto it.

Then the unglamorous plumbing: predicting which water main or stretch of road is about to fail and fixing it before it floods someone's street. Tuning the heating in schools and hospitals so they stop burning money. Working out where the ambulances should wait so they reach people faster. None of this makes a flashy demo. All of it changes someone's actual day.

And the one closest to my heart — routing that avoids the steps, the broken pavements, the dark underpass. Nobody puts accessibility tech on the conference poster. But for the man on my high street, that's not a feature. That's whether he can get to the shops alone.

Notice what every one of those has in common. A clear job, a saving you can point at, and no need to know who anyone is.

The stuff I'd fight before it's installed

Now the basket gets darker, and the danger is that the cost never shows up on the day you buy it. It shows up years later, on someone else.

The camera that smooths the traffic can run facial recognition with a software update. The sensor listening for noise can pick out an individual. Once that hardware is bolted to the lampposts, deciding not to use it that way stops being a setting and becomes a political brawl — one that residents usually lose. You have to draw that line before the kit goes up, because afterwards the kit decides.

Vendor lock-in is the boring trap that bites hardest. Sign with the wrong supplier and you can lose the right to switch, to open your own data, or to change your mind. That's not a software preference. That's handing a private company a chunk of your city's nervous system.

And then the systems that decide where to send police patrols or which homes to inspect — trained on yesterday's data, they faithfully reproduce yesterday's unfairness, aimed at the same communities that have always been over-policed and under-served. The bias isn't in anyone's intentions. It's baked into the history the model learned from, which is exactly why it keeps happening.

The one that makes me angriest is exclusion dressed as progress. A service that requires an app, or a digital ID, or being online — that's a service that has decided the elderly, the homeless, and the newly arrived don't count. A city that locks people out of the basics to look modern has failed at the only thing a city is for.

What I'd write into the contract, in ink

Some places have already worked out the right defaults, and I'd shamelessly copy them. Amsterdam publishes a register of what each of its algorithms does and how you can challenge it. Estonia lets residents see who looked at their data and why. Copenhagen shares back what the city collects. Barcelona uses tech to summarise what citizens say, not to replace asking them.

Translate all that into plain contract language and it comes out as a short, stubborn list. Every system that makes decisions about residents is documented publicly. Collect the least data, keep it the shortest time, don't stitch datasets together on a whim. No facial recognition in public spaces — full stop, no asterisk. The city owns its own data. And you ask people before you build, not after, in a way that can actually change the answer.

So here's the test I'd apply to anything in that basket, on behalf of the man on the high street. Does it need to identify individuals to do its job? And if it goes wrong or gets breached, who pays, and can it be undone? The adaptive traffic lights pass both, easily. Public facial recognition fails both, badly. Most things sit in between — and that uncomfortable middle is precisely where someone has to fight for the right clauses.

The best cities I've seen aren't the ones bristling with the most sensors. They're the ones that decided who they were building for, and what they'd refuse to build, before a salesperson decided it for them.

Dimple Paratey
Dimple Paratey
Chief Marketing Officer

Dimple leads marketing at Partech Systems. Before that she spent fifteen years in telecoms, mostly working in the gap between what the engineers built and what customers actually understood. She writes about the human side of technology — the people using it, the ones it tends to leave out, and the stories that get lost when we only talk in features and roadmaps.