Case study · 2021 → 2022
CityFlow
One platform for the municipal teams who actually fix the city: the animal centre, the parks service, the road infrastructure division. Their work ran on paper, Excel and personal WhatsApp. The job was to digitise it without flattening three services into one.
At
Role
My part
Worked with
Status
How it started
The city could not see its own work. It lived on paper, in spreadsheets and in personal WhatsApp threads, so nobody could say reliably what needed doing, who was doing it, or whether it got done.
The brief from the Município do Porto was an integrated system for its operational divisions: digitise the processes that exist, standardise the internal flows, speed up communication between teams, and record who did what and when. Three services came in as the first clients. The animal centre, the parks and green spaces division, and road infrastructure.
What the discovery found was that almost none of it was digital. Weekly plans were built in Excel on a Friday, printed, and pinned up at the clock-in location for the crews. Field teams sent each other photographs of the work over their own WhatsApp accounts. At the animal centre the cages were managed on paper and updated by hand. One service put it plainly: there was no platform to record or see occurrences, and they had more than once sent people to the same place twice.
The constraints came from the same visits. Clock-in locations have no computers and no internet. Many of the gardeners have little reason to be confident with software, so a device each was never realistic and a shared one was. Road infrastructure was already digital but not automated, so the team traded print screens of the supervision system to pass an occurrence along. Whatever got built had to survive that, not a demo.
Process
Discovery, run by the service design team
Interviews with the three services, a collaborative session at the Porto Innovation Hub, and field visits to each one, led by the service design team with external consultants. I did not run it. I was in every session and reviewed what came out of them, because those conclusions set the roadmap and decided which features the early releases would carry.
Watching the work where it happens
The animal centre, then a parks clock-in location, then a road tunnel. Colour codes on cages, the daily kaizen board, the sheet of paper that says which gardener goes where. You cannot design a replacement for a paper process you have only heard described.
The pattern under three vocabularies
Each team named things differently and each was sure its process was unlike the others. Set side by side, the shapes matched: something is reported, it becomes a task, someone is assigned, an asset is touched, a record closes. Different words, same skeleton. That finding is what made one platform possible instead of three.
Workflows as data, not as code
BPMN was chosen so that a process is a model, not code. A service can change its own flow without a release: no deployment, no engineering ticket, no waiting in a queue behind somebody else's feature. Each vertical keeps its own rules, the platform underneath stays one thing, and a process can change the week the service changes.
A first release small enough to be wrong
Four things only: occurrences and interventions, asset management, search, and notifying somebody that a task is theirs. Assets meant animals, cages and people at the animal centre; tunnels and equipment on roads; gardens and their contents in parks. The same four capabilities, filled in differently by each service.
Three pilots, chosen to be honest
The animal centre ran it with the whole team, being small enough to cover every profile. Parks ran at least three clock-in locations with their weekly maintenance plans configured. Roads ran a single tunnel, where one contractor controls everything. Narrow enough to fix, real enough to fail.
In both tracks at once
Discovery did not finish and then hand over. The service design sessions ran alongside the development and requirements teams, who were working in sprints, and the first release was the point where the two methods had to meet. I was in both: every discovery session, and the build. So the interface got drawn while the processes it served were still being decided, and it had to read to a veterinary nurse, a parks foreman and a control room operator, none of whom had asked for new software.
From recommendations to a running product
The discovery phase closed in November 2021 with a report. Specialists rotated through the project as each phase needed them, which is how it was resourced and how it should be. What cannot rotate is the person carrying the product itself: deciding what the next iteration holds, saying no to the rest, and keeping three services in agreement while the thing changes underneath them. That part became mine.
Decisions
Tradeoff 01
Standardise the container, not the work
The brief said uniformise processes across the divisions. Taken literally that means telling a veterinary team and a road control room to work the same way, and losing both. BPMN let the platform hold one shape while each service kept its own flow and its own rules. What got standardised was the structure, not the job.
Tradeoff 02
One shared device, not one each
The obvious answer to field work is a phone per operative. The field visits killed it: those locations have no internet, and many crew members had no reason to be comfortable with software. A shared device at the clock-in location was less elegant and was the only version that would be used.
Tradeoff 03
Keep the paper that earns its place
Not everything on paper was a failure of digitisation. Cage cards are read at a glance by someone with their hands full, and end of cycle decisions have to be printable. Digitising those first would have made the work harder and lost the room.
Tradeoff 04
What the first release refused
Stock and consumables, human resources, dashboards and KPI reporting, geolocation and maps, and a public interface for animal adoption. Every one was asked for and every one was named as a later iteration, because a first release that does four things well is testable and one that does twelve is not.
The product
Outcome
The goal the city set was faster, traceable operations across divisions that had never shared a system. This is the part a platform can take.
What it could be held to was narrower: whether three services with different vocabularies, different tools and different levels of comfort with software would use one platform for real work.
Everything below is attributed. The discovery findings belong to the service design team, the process validation to the client services, and the figures to whoever published them.
From the field visits
The processes were deeply analogue and on paper, which made the work impossible to monitor. Planning was done in Excel and pinned to a wall. Crews passed photographs of jobs over personal WhatsApp. One service had sent people to the same location more than once because there was nowhere to see what had already been reported.
From the client services
At the joint session in November 2021 the three teams reviewed the service blueprints and the uniformisation of processes was validated, with corrections fed back in afterwards. Getting a veterinary service, a parks division and a road control room to agree that their work has the same shape is the result that made everything after it possible.
From the three pilots
The stated expectation was that control cycles running weekly or monthly would become near instant, because information would move in real time rather than on a printed sheet. What the pilots put to the test was whether a process could be digitised end to end, and whether every step that could be automated actually was: the report generated rather than typed, the record passed to the next department rather than emailed, the next person notified rather than telephoned. What came back was a working system the teams used, and a loop that closed. When the crews on the ground said a step was wrong, the flow could be changed in the model rather than argued over or queued behind a release, and the corrected process reached them quickly. That is the architecture proving itself inside the pilot, which is the earliest anyone could have known.
Reported by Porto Digital
In April 2026 Porto Digital took CityFlow to the Eurocities Digital Forum in Sofia and described it as a modular platform for integrated management of urban services, mature, tested, and ready to be adopted by other cities. That July the city closed an eighteen month programme, funded under the Plano de Recuperação e Resiliência, which had grown it to ten operational verticals. Those are the city's figures for a programme that ran years after I came off the project, not a reading of the release I worked on.
The part that was the bet
The word the city uses for it now is modular. That was the whole wager in 2021: put the process in the model rather than in the code, so a service could change its flow, or a new service could be added, without a release. Ten verticals is the version of that bet I did not stay to see, and it is the only claim on this page I would make about the years after mine.
What this cannot show
Whether the city fixes things faster. Contracts, staffing, budget and weather all act on that, and a platform is one input among them. It can show that the record now exists, which is the precondition for anybody ever finding out.
The lesson I took was about vocabulary. Three teams each believed their process was unique, and each was right about the words and wrong about the shape. Most of the work was not designing screens, it was proving to people who had never met that they were doing the same thing, and then building something that let them keep their own language while sharing a spine.