Most smart city programmes buy sensors before they can act on what the sensors report. The sequencing should be the other way round.
There is a familiar shape to smart city programmes. Sensors are procured. A dashboard is commissioned. There is a launch event with a large screen showing live data. Two years later the screen is still there, and the drainage still floods in the same place.
The failure is not technical. The data usually arrives correctly. What is missing is the part nobody budgeted for: a person whose job it is to act on the signal, and a process that gets them there.
Instrument what you can already respond to
The useful test before installing any sensor is simple: if this reports a problem at 2am on a Sunday, what happens?
If the honest answer is "it appears on a dashboard someone reviews on Monday", then the sensor is measuring, not helping. That may still be worth doing for planning purposes, but it should not be confused with an operational improvement.
Programmes that deliver value tend to start from the response capability and work backwards. There is a team that fixes street lighting, so instrument street lighting. There is a crew that clears blocked drains, so instrument the drains that block. The sensor closes a loop that already exists rather than creating an obligation nobody owns.
Permits and approvals are the highest-return digitisation
Sensors get the attention; administrative workflow gets the results.
Construction permits, business licences, land searches and change-of-use approvals are high-volume, high-friction processes with well-defined steps. They are also processes where delay has a direct economic cost — a stalled approval is a stalled investment.
Digitising these well means more than putting the form online:
- Every application has a status the applicant can check without phoning.
- Each step has a named owner and an elapsed-time measure.
- Bottlenecks are visible to management as a queue, not discovered in a complaint.
- The decision and its reasoning are recorded, so precedent is consistent.
That last point matters more than it appears. Inconsistent decisions on similar applications are among the most corrosive things a permitting authority can produce.
One identity across services
Residents do not experience departments. They experience a city that asks them to prove who they are four separate times.
A shared identity layer — with proper consent and access controls — is what makes the difference between several digital services and a coherent digital government. It also makes the data useful: without it, nobody can answer whether the person reporting the blocked drain is the same person who paid the rates on that property.
This is politically harder than it is technically hard, which is why it is often skipped. It is also the thing most worth doing.
Interoperability protects the next administration
City systems outlive the teams that commission them. A platform that cannot export its data, whose integrations are proprietary, and whose vendor holds the only copy of the schema is a liability handed to whoever comes next.
Open formats, documented interfaces and an explicit right to your own data are not procurement box-ticking. They are what makes the second phase possible at reasonable cost.
Phasing that survives political cycles
Long programmes that deliver nothing for two years tend not to survive a change in leadership. The programmes that endure deliver something visible early, then compound.
A workable sequence:
- Digitise one high-volume administrative process end to end.
- Make its performance publicly measurable.
- Add a second process sharing the same identity and payment layers.
- Instrument physical infrastructure where a response team already exists.
- Build the aggregate view once there is real data to aggregate.
The dashboard comes last, not first. It is a byproduct of working systems, not a route to them.
Where we fit
We build permit and licensing workflows, asset and property management systems, IoT data pipelines, and the integrations that let city systems share identity and payment infrastructure. Most of our work here is incremental and process-first rather than platform-first.
See our infrastructure and IoT page, or tell us what you are planning.