Why the Best Smart-City Technology Can Still Be Useless

From Toronto to Kochi, smart-city schemes have shown that working technology is not the same thing as an operating public service. The projects that scale treat data, budgets, authority and vendor exit as infrastructure questions, not IT details.

Sidewalk Labs, Alphabet's urban-technology company, arrived at Toronto's waterfront with a big proposition. Its Quayside scheme promised a sensor-powered neighbourhood, a highly visible version of what many cities had begun to imagine: streets, buildings and services made more responsive by data.

The project was announced in 2017. It was abandoned in May 2020.

That sequence is often filed under the familiar heading of smart-city overreach. Too much technology. Too much ambition. Too much money. But the dispute that mattered was more awkward than that. Quayside ran into controversy over data privacy, governance and financing frameworks. The design could be discussed. The technology could be demonstrated. What was not settled credibly enough was who had legitimate authority over the digital life of a public neighbourhood.

That is a useful place to start because Quayside was not a broken sensor. It was a warning about the order of operations. A city cannot first buy a digital nervous system and later decide who is allowed to use it, who answers to the public for it, and who keeps it functioning once the original sponsor leaves.

The question is simple: when a smart-city pilot works, what exactly has been proved?

Usually, only that the technology works.

The expensive misunderstanding

Cities are routinely told that their main obstacle is technical complexity. They need connectivity, sensors, a platform, analytics and a control room. All of those things cost money. All of them can be difficult to install.

Yet the record suggests a different bottleneck. 1001 Smart Cities, a project that tracks smart-city schemes and records projects it classifies as failed or scaled back, has assembled a failure atlas covering 1,147 projects. It records 107 as failed or scaled back. That does not make the atlas a final verdict on every project, and it cannot establish a universal failure rate for all smart-city investment. Its value is narrower, and useful: it documents repeated cases where a system produced measurements but no institution was obliged to act on them.

A sensor can show congestion. A dashboard can identify a risk. Neither can instruct a transport department to change a route, release a maintenance budget, or share information with a utility that controls another piece of the problem.

This is where most people stop looking. They see a screen full of data and assume the city has acquired a capability. In reality, it may have acquired a screen.

A smart-city system should be thought of as an operating infrastructure service, closer to a water network than a software demonstration. It needs an owner. It needs rules. It needs maintenance. Above all, it needs a reliable way to pay for itself after the launch event is over.

That is why a subsidy can exist without becoming usable finance. Demonstration funding may purchase the first deployment. It does not automatically fund the people, cyber protection, software, connectivity and institutional work required every year afterwards.

Kochi's control room met the real city

Kochi, a city in India, built an Integrated Command and Control Centre through India's Smart Cities Mission. The centre was intended to bring multiple urban services together. This is the model that photographs well: a central room, integrated information and a city that appears newly manageable.

But an independent academic analysis published in March 2025 found that the centre did not mature into a city-wide system. The problem was not presented as an inability to collect data. The problem was that a top-down mandate entered a local environment shaped by bureaucratic fragmentation, electoral political turnover and weak integration with existing municipal authority.

Kochi's control-centre model exposed the gap between integrating information and integrating municipal authority. Photo: Ibrahim Boran / Pexels, Pexels licence (free commercial use).

Imagine you are responsible for a city service. A new centre sees the problem before you do. But it cannot direct your staff, control your budget or resolve a conflict between agencies. What has been integrated is information, not action.

Kochi exposes the flaw in the phrase "integrated command centre". Integration is not a property of a building or a dashboard. It is a property of authority. If the permanent municipal bodies do not have defined responsibilities, the command centre becomes a highly informed observer.

The interesting part is that this is not a uniquely Indian problem. Technology can be placed on top of a city far faster than a city can rewrite the lines of accountability underneath it.

Japan's missing step was not invention

Japan offers a quieter version of the same story. The OECD reported in 2023 that only 23 smart-city projects had become mainstream services by 2020. The country's problem was not a shortage of pilots. It was the journey from experiment to normal public service.

Local governments faced constrained revenue streams and tightly earmarked budgets. Projects remained isolated. Cross-project data and governance standards were missing.

That number, 23, is not a measure of whether Japanese technology was good or bad. Nor can it be compared mechanically with Kochi's command centre or Amsterdam's Energy Atlas. They sit in different political systems, serve different purposes and faced different local conditions. The comparison is useful only in one limited sense: each case directs attention away from the gadget and towards the arrangements that decide whether a pilot becomes part of a normal public service.

A successful pilot has a habit of making its sponsors believe that success will spread naturally. It rarely does. One neighbourhood can use a tool because a dedicated team is available, a grant is in place and the vendor is still attentive. Scaling means another department must accept the operating cost, another system must exchange data, and somebody must make a decision when things go wrong.

A pilot is a test. A mainstream service is a promise.

Put Kochi, Japan and Quayside side by side and a pattern appears that none of the cases says quite so plainly: cities often treat the pilot as a technical proof before they have decided whether they can make the political and financial promise required by a permanent service. The gap is not between innovation and scale. It is between a demonstration and an institution.

This is also why smart city financing cannot begin with the price of sensors. It begins with the lifecycle question: what will the continuing cost be, which public body has the budget authority, what public value or commercial revenue supports payment, and who carries the risk if the system is compromised or the supplier exits?

Melbourne had the data, but not the control

Melbourne, in Australia, provides another correction to the idea that open data is the answer. Research on Melbourne's smart-city data initiatives found sensor networks, open data and mobility technology. Yet governance remained fragmented across federal, state, local and private actors.

The city lacked authority over key datasets and operations. Open-data platforms existed, but centralised governance did not. Meaningful integration and accountability suffered.

Here is the twist: data being available is not the same as data being governable. A file can be open and still be unusable in an operational sense if nobody can set standards, join systems, decide permitted uses or require a response.

For founders, this distinction is commercially important. A city may enthusiastically procure a product and still be unable to offer what an operator needs to build a durable service: access to the relevant information, an integration route into other systems, a responsible counterparty and a budget that survives the pilot.

The U.S. Government Accountability Office found in 2025 that procurement officials often lack expertise to craft contracts defining data governance and ownership. The result can be vendor lock-in, cybersecurity exposure and systems left orphaned when a pilot ends.

Vendor lock-in means a city becomes dependent on the supplier it first chose, even when another provider might do the job better or more cheaply. In ordinary language, the city buys a door but not the key.

A good procurement must answer questions that tend to be pushed into appendices: Who owns and can use the data? Can it move to another provider? What standards allow separate services to communicate? Who bears cyber liability, meaning responsibility for losses when a digital system is breached? What happens to the service when the vendor contract ends?

Those are not legal niceties. They determine whether a future lender or strategic partner is looking at an asset that can operate, or a bespoke experiment attached to one supplier.

Amsterdam did the unglamorous work first

Amsterdam's Energy Atlas, a Netherlands project that used city data in an energy context, points in the opposite direction. OECD analysis identified a strong governance link between the pilot team and the parent municipal organisation, alongside partnership frameworks and shared commitment among stakeholders.

That connection enabled scaling.

Amsterdam's Energy Atlas scaled because the pilot was tied to the municipal organisation expected to operate it. Photo: Trang / Pexels, Pexels licence (free commercial use).

Notice what is absent from that lesson. There is no claim that Amsterdam possessed magical technology unavailable to Kochi, Melbourne or Japanese municipalities. Nor does this one case prove that governance alone caused the outcome. It does show something more practical: a pilot had a deliberate institutional route into the organisation expected to keep it alive.

That should alter how a city approaches a smart city PPP, a public-private partnership. The private participant may supply technology and implementation skill. But unless the city retains a clear operating role and the contract settles control of data, integration, continuing costs and exit, the partnership has merely postponed the central problem.

Dallas Red Cloud, a smart-city intervention in a troubled neighbourhood in the United States, offers a grounded counterexample. Axios reported in 2023 that the intervention delivered measurable crime-reduction and quality-of-life improvements. The available account attributes the result to alignment among municipal operational control, funding and implementation, rather than treating technology as a stand-alone answer.

Dallas Red Cloud demonstrated that smart-city tools can deliver measurable results when funding, implementation and municipal control align. Photo: Nuray / Pexels, Pexels licence (free commercial use).

The evidence does not provide a comparable full lifecycle cost schedule for Dallas, Kochi, Melbourne or Amsterdam. That matters. No investor should infer a precise return, recurring bill or savings figure from these cases alone. But the absence of those figures is itself revealing: a city that cannot quantify its recurring operating bill, identify the body that captures any savings, and show what happens when a supplier exits has not yet produced a financeable operating case.

The old water-system lesson

The pattern is older than the phrase "smart city". A compiled account of donor-funded water and sanitation systems reports that 30% to 40% fail worldwide because of poor maintenance, stakeholder engagement and planning, rather than because pipes are missing.

The comparison is uncomfortable because it strips away the glamour. A water system fails when nobody maintains it, pays for it or owns the difficult decisions. A city digital system can fail for the same reason, only with dashboards instead of pipes.

The underlying rule is simple enough to repeat at dinner: infrastructure is not what gets installed. Infrastructure is what somebody remains responsible for on a bad Tuesday years later.

GI Network's view: A smart-city pilot is bankable only when the city can show the full chain from asset and data control to operational authority, recurring payment and vendor exit. Anything less is a demonstration with an uncertain afterlife.

What cities should demand before the pilot

Municipal leaders do not need to become software engineers. They do need to stop procuring isolated products as if an impressive demonstration were the same as a service model.

Start with an asset inventory. Which sensors, networks, platforms, datasets and existing city systems are already in place? Which agency controls each one? Without that map, a proposed integrated service is likely to discover its dependencies after contracts have been signed.

Next, name a permanent operating owner before the pilot begins. Not a temporary project team. Not a vendor-funded unit. The named city body should have authority to act on the information the system creates and a defined route to pay the recurring bill.

Then require a quantified post-pilot schedule. It should separate the recurring costs of operating staff, software, connectivity, cyber protection and maintenance from one-off deployment spending. If savings are offered as the payment source, specify who receives them, how they are measured and whether that same body can use them to pay the service. The research cases do not supply a universal cost benchmark. They do make clear why leaving this arithmetic until after the pilot is dangerous.

Make interoperability, the ability of systems to exchange and use information, a procurement requirement. The city should establish its data rights, rules for sharing data, and the conditions under which it can move data or services away from a supplier. It should also allocate cyber responsibility plainly rather than assuming the issue disappears inside a technology contract.

That discipline protects flexibility. It is the municipal version of the warning that control given up in a deal may not appear in the cap table. A city can surrender future room to manoeuvre without selling a single asset, simply by signing a contract that leaves data, integration or exit in somebody else's hands.

What investors should ask before calling it infrastructure

Investors should be wary of a seductive but incomplete story: a large city, a credible technology supplier, a pilot budget and a promise to expand. That is evidence of interest. It is not necessarily evidence of a financeable service.

Ask first who pays after the pilot. Is the payment supported by a city body with the authority to commit it? Is it based on an identified revenue source, or on savings that are measurable and actually captured by the body paying the bill?

Ask for the numbers that turn a demonstration into an operating case: the recurring annual cost categories, the contracted payment route, the length and conditions of the supplier agreement, and the costs or responsibilities triggered by a cyber breach, data dispute or supplier exit. A contract can look substantial while leaving all three risks with the operator. That is not infrastructure income. It is exposure wearing a municipal badge.

Ask who owns the operational relationship. If a provider requires access to municipal data but the city lacks authority over key datasets, Melbourne shows how quickly the commercial case can weaken. If a national programme funds a command centre but local authorities do not control its use, Kochi shows the danger of mistaking central backing for local operating capacity.

Then test transferability. Can another provider take over? Can the city access its data? Are integration rules clear? Can a lender understand the risks created by cyber events, supplier departure or a change in political leadership? These are the same instincts behind asking why a major contract can still fail to support borrowing. The existence of a customer is not enough. The quality, durability and enforceability of the cash flow matter.

Experienced investors are not being anti-technology when they ask these questions. They are pricing the difference between a product sale and an enduring operating service.

GI Network would approach this situation by mapping the proposed system's assets, data rights, operating owner, contract dependencies and recurring payment route before investor outreach. We would test whether the cash flows can be underwritten, identify where procurement terms create vendor or cyber exposure, and rehearse the objections an investment committee will raise about control, integration and post-pilot funding.

Use the AFTER test

Before approving a pilot, run the AFTER test. It is a five-part check drawn from the failures and successes above:

• A, Authority: Which permanent public body can act on the system's information?
• F, Funding: What are the recurring costs, who pays them, and which body captures any savings?
• T, Transferability: Can data and services move if the supplier changes or exits?
• E, Exchange: Do systems have rules and standards to work together?
• R, Responsibility: Who carries operational and cyber responsibility when something fails?

If any answer is vague, the city has not yet designed digital infrastructure. It has bought a pilot.

That is not a reason to stop experimenting. It is a reason to make the experiment answer the question that matters: who will still be responsible after the novelty has gone?