Smart Cities Were Supposed to Fix Traffic. They Mostly Didn't.

The Indian government rolled out the Smart Cities Mission a little over a decade ago now. It covered a lot: traffic, waste management, sewage, more. In college I'd heard the name and had no real idea what it was meant to do. When I started building TraffiCure and actually looked into it, I was genuinely thrown. This was supposed to fix traffic? Then why has traffic gotten worse in almost every city it touched, not better?

It took about three months of continuous conversations with cities to actually understand what "smart city traffic" meant on the ground. There were two separate workstreams: management and enforcement.

Two problems wearing the same uniform

Enforcement is everything tied to challans: wrong-side driving, red-light jumping, and so on. It's useful, and I'd argue important on its own terms, mostly for safety. But enforcement and congestion are two different problems wearing the same uniform. Is Indian traffic bad because people don't follow rules? Some of it, sure. But someone running a red light, or three people on a bike without helmets, is a safety issue first. It doesn't automatically add a single extra minute to anyone's commute. I think enforcement matters enormously for safety. I don't think it does much for congestion, and treating the two as the same problem is where a lot of this goes wrong from the start.

Management is the real traffic engineering: timing signals, deciding which roads are actually the cause of congestion and worth fixing, deciding what new roads need building. And cities did invest in both. Their tenders were explicit about what they wanted: hardware for enforcement, vehicle count data from those same cameras and sensors, and Adaptive Traffic Control Systems, or ATCS, installed at a number of signalized junctions.

Where Adaptive Traffic Control (ATCS) falls apart

The idea behind ATCS, in principle, is simple: instead of running a junction on a fixed timer, let the signal read live traffic and adjust itself. The mechanics are straightforward: a sensor watches the tail of an approach into a junction, and when it sees vehicles building up, it shortens the wait and lets that side through.

It's worked in the West for decades, in various forms, because it's built on one quiet assumption, that most of the time, nothing is actually waiting there. An approach defaults to red and only turns green once the system detects a vehicle. That assumption doesn't survive contact with an Indian junction. At almost any hour, peak or otherwise, every approach already has something sitting in it, cars, bikes, e-rickshaws. There's no empty state for the sensor to react to.

And even where it tries, these systems should really be timing signals off queue length, and queues here routinely run past 100 metres. Most of these cameras can only read 10 to 20 metres of road before the image quality falls apart. The system was never actually looking at the queue. It was looking at a sliver of it and guessing at the rest.

The system was never actually looking at the queue. It was looking at a sliver of it and guessing at the rest.

I live in Gurgaon, and since the ATCS rollout here, I've personally watched traffic get worse at more than one junction. I'll admit that upfront: a personal anecdote is not evidence, and I hold everyone else to that same standard. Fine, don't take my word for it.

Every one of these decisions, installing an ATCS, picking an algorithm, closing a lane, building new infrastructure, should be provable with data: a simulation before, a real before-and-after after.

And here's the thing: the sensors were already capturing exactly that. Vehicle counts, speeds, the raw traffic metrics that would tell anyone, definitively, whether any of this is actually working. Surely, with sensors sitting on hundreds of junctions across the country, somebody has pulled those numbers and checked?

So I went looking for the data

That's what I went looking for. What I found instead was worse than I expected. Here's what that actually looks like in practice, from my own first-hand experience with it.

When Google needed to calibrate its vehicle-count data against real sensor-collected volumes, I went to a major smart city to pull seven days of data across their camera network. I assumed this was a SQL query, maybe an afternoon of work. It wasn't. The vendor's system locked the city into its own interface, and that interface could only export one camera, one day, at a time, into an Excel sheet. Seven days across roughly 200 cameras meant running that export 1,400 times. It took the city almost a week just to hand over the data.

Why one day of data answers nothing

Second problem, and this is the one that actually matters more: a lot of cities don't retain historical data at all. One month, sometimes less, and it's gone. That's not the city's fault, it's what happens when a vendor treats data retention as an afterthought.

Here's why that's a real problem and not just an inconvenience: you cannot tell whether an intervention worked, a retimed signal, a new ATCS, a closed lane, from a single day of numbers. Traffic moves with the day of the week, the season, a dozen things that have nothing to do with whatever you just changed. Telling a real improvement apart from normal noise takes months of comparable history, not a snapshot. Best case, most cities get a daily Excel report of yesterday's volumes. One day of absolute numbers can't answer anything, not against last month, not against before the change, because by the time anyone asks the question, there's no "before" left on record.

Not a knock on the cities

None of this is a knock on the cities. They wrote the requirements. The vendors delivered the bare minimum against them, sensors and cameras running in silos, producing numbers that vanish after a day, built in a way that makes it structurally difficult for a city to ever run real analysis on its own data. It's a strange place to end up in: government sitting on top of a genuinely rich corpus of traffic data, in an era when every enterprise around it is doing serious things with data science, and unable to actually touch its own numbers. That gap, between the data a city already owns and what it can actually do with it, is the whole reason we built TraffiCure on Google's Roads Management Insights.

What this means for us cuts both ways. When I walk into a city now, I'm usually walking into a room that's already been burned once, and the authorities I meet have gotten allergic to bullshit. They've seen what crores of spend on "smart" infrastructure gets you when nobody asks what the data is actually for. So they've stopped asking for data points and started asking harder questions: what road should I build, what happens if I close this one, how do I actually optimize this junction's signal timing, not just retime it and hope. It makes selling this harder than it used to be. It also means we can't get away with shipping a dashboard and calling it done. If anything, it's the best filter we could have asked for.