The Smart City Breaks Between the Systems

When people talk about smart cities, the image is usually a control room. A wall of screens shows traffic, energy use, air quality, public transport and emergency services. Sensors feed data into dashboards. Algorithms identify patterns. Somewhere above the city, the city appears to understand itself.

I have never experienced a city through its control room.

I experience it while trying to work out which bus app is correct. I experience it when a public service exists but is almost impossible to find, when a sign disagrees with a website, when a form asks for knowledge only the institution has, or when a map tells me where something should be but not whether it still works.

This is the part of the smart city that interests me. Cities may already have plenty of intelligence inside individual systems. The failure often appears between them.

A transport agency can have accurate vehicle data while the display at the stop is wrong. A hospital can have advanced equipment while an ambulance routing system still struggles to decide which hospital is actually appropriate for a particular patient. A municipality can publish thousands of datasets while a resident cannot answer a simple question about whether a beach is safe, a road is closed or a permit has been approved.

Each component can be working according to its own definition of success. The complete journey can still fail.

The resident experiences the seam

Organizations tend to see systems separately because separate teams own them. There is a transport system, a healthcare system, an identity system, a payments system and a public information system. Vendors are contracted to deliver particular components. Departments have their own budgets, metrics and legal responsibilities.

A resident does not experience these boundaries as an organizational chart. They experience them as confusion.

The bus app sends them to a stop that has moved. The payment system accepts their money, but the access gate does not recognize the purchase. The digital form is available in several languages, but the confirmation email is not. The city says a service is public, but the building that contains it closes before most people finish work.

These are not spectacular failures. They rarely become the central image in a smart-city presentation. Yet they determine whether the city feels coherent.

I keep returning to public Wi-Fi because it is such a small and revealing example. The technical infrastructure may already exist. Routers have been purchased, connections installed and access points registered. From the perspective of the organization providing the network, the service is real.

From the street, the situation is less certain. Which network should I join? Is it genuinely public? Does it still work? Is it accessible from outside the building? Will the captive portal load on my phone? Who updates the information when the café closes, the library changes its hours or the router disappears?

WiFi.ee began as a database of public wireless networks, but rebuilding it has made the surrounding problem more visible to me. A list of coordinates is not the service. The service also includes verification, signage, ownership, maintenance, reporting, accessibility and the expectation that somebody will notice when reality stops matching the database.

The router is only one component. The public experience exists in the connections between all the others.

Smart infrastructure can still produce a stupid journey

Emergency medicine makes the consequences more serious. An ambulance can be fast, digitally connected and well equipped, yet still operate inside a fragmented journey. The nearest medical facility may not be the facility with the staff or equipment a patient needs. Information collected in the ambulance may not arrive in a form the receiving team can immediately use. A technically efficient transfer can still lose time at the boundary between organizations.

The design question is not only how quickly the ambulance moves. It is how the entire system recognizes the situation, chooses a destination, transfers responsibility and preserves information while the patient moves through it.

That is a different kind of smartness. It is less visible than adding another sensor or predictive model because it depends on coordination, protocols, interfaces, fallback procedures and institutional trust. It requires someone to care about the whole sequence even though no single organization completely owns it.

This is where the word interface becomes slightly misleading. We often imagine an interface as the screen placed on top of a system. In public services, the interface may be the point where two institutions exchange responsibility. It may be a sign beside a physical entrance, a phone call between professionals, a field missing from a database, or a rule deciding which organization is allowed to act.

The seam is an interface too.

Many digital projects try to smooth these seams at the surface. A new portal is created so residents can access several services from one place. A dashboard collects information from different agencies. A city app promises to make everything available through one account.

Sometimes this helps. Sometimes it hides fragmentation without resolving it. The resident receives one front door, but behind it the same disconnected processes continue. They submit information once and are asked for it again. They see a unified status page, but nobody can explain why the case has stopped moving. The interface becomes coherent faster than the institution does.

This may be why smart-city projects so often feel both impressive and strangely distant from ordinary urban life. The technology is usually procured as a component. The resident experiences a chain of components. Nobody is being paid to own the chain.

The missing work is integration, but not only technical integration

Systems integration sounds like an engineering problem. Sometimes it is. Databases need to exchange information. APIs need stable contracts. Identity and permissions need to work across services.

But the harder integration is often organizational and experiential.

Who is responsible when the information is technically correct but practically misleading? Who notices that a service works on a desktop but fails at the location where people actually need it? Who can change a process that crosses three departments? What happens when the optimized result for one institution creates a worse journey for everyone outside it?

Traditional UX work can also stop too early here. It may improve the form, app or dashboard while leaving the surrounding service untouched. The screen becomes easier to use, but the resident still has to understand the organizational structure to complete the task.

The more interesting role is not designing one interface. It is following the experience until the institutional boundaries become visible, then treating those boundaries as part of the design problem.

This is where I now see HAAM fitting into smart cities. Not as another company promising to make cities intelligent, and not as a supplier of a single urban technology. The work is closer to finding where infrastructure, software, information and operations stop behaving like one system, then taking responsibility for making the connection work.

That might involve a map, a database, a public interface or a piece of signage. It might also involve deciding who verifies the data, how a failure is reported, what happens when an external service disappears and which organization owns the next action. The visible design is only one part of the repair.

Raw Drafts has a different role. It can notice the seam before there is a project around it.

A missing Wi-Fi sign, a confusing ambulance route, an event app that misunderstands why people attend, or a train that is fast only on the section of track built for it can look like unrelated observations. Writing lets me follow them far enough to see the structure underneath. A small awkward moment often reveals a larger disagreement between technology, institutions and everyday behaviour.

Raw Drafts finds the seams. HAAM fixes some of them.

I am still cautious about calling this smart-city work because the category carries so much baggage. It can suggest surveillance, command centres, vendor platforms and cities optimized from above. The problems I care about usually appear much lower down, at the moment someone tries to do an ordinary thing and discovers that the systems around them do not quite meet.

Perhaps a genuinely smart city is not one that knows everything happening inside it. It is one that notices when the journey breaks between the things it already knows.

For now, I keep thinking about the public network that exists in a database, inside a building, behind the wrong door, with no sign outside. Every component can report success. The person on the street still has no internet.

That gap feels like enough work for a long time.

Connected reading

• The City Is an Interface
• The Best Products Aren't Apps. They're Cities.
• The System Around the Medical Model
• The Interface Arrived Before the Institution

AI authorship note

This essay grew from Kris Haamer asking how HAAM and Raw Drafts relate to smart cities, then rejecting the broad category in favour of a more specific problem: cities fail at the seams between systems. AI supported drafting, editing and implementation. Kris selected the argument, sharpened the positioning and approved the essay for publication.