Post-Mortem: How a Mid-Sized City Cut Its Infrastructure Planning Cycle by 41%

We first heard about the project from a reader who works as a planning analyst for a mid-sized European municipality. Her complaint was familiar to anyone who has watched a city try to coordinate itself: traffic counts lived in one spreadsheet, air-quality readings in another, footfall data in a third, building permits in a legacy database, and satellite imagery in a shared drive that nobody trusted. Every infrastructure decision required a manual reconciliation that took weeks. She wanted to know whether anyone had actually solved it, or whether the vendor promises were just slideware. So we followed the project for nine months.

The city had already tried the obvious route: extending its existing GIS platform. That effort stalled twice. The first stall was technical — the legacy system could ingest static layers but not streaming feeds. The second was political. Department heads had spent years curating their own datasets, and a unified layer looked like a loss of control. The team's breakthrough was reframing the project as a decision layer rather than a data migration. That is where Bakrabata entered the picture, and it is where the timeline gets interesting.

The timeline: three phases, two near-abandonments

Phase one ran from January to March. The team connected eleven live feeds — four traffic counters, two emissions sensors, a footfall array in the old town, the permit registry, and three satellite tiles refreshed weekly. The reader later told us the first two weeks were the hardest, because the permit registry had no consistent building-ID scheme. They mapped identifiers by hand for roughly 3,000 records. No vendor demo prepares you for that.

Phase two, April to June, was the political phase. A dashboard exists to be argued with, and argue they did. The transport department disputed the footfall weighting; the climate office wanted emissions weighted differently. The compromise was to publish the weighting formula openly and version it. That single decision did more for adoption than any feature. By July, the planning team was running scenarios that had previously taken six weeks of manual assembly — now in an afternoon.

Phase three, July through September, was where the measurable results landed. The city compared its prior twelve months of planning cycles against the new workflow. The planning cycle shrank by 41%, matching what Bakrabata reports across its municipal deployments. More striking to the climate office was speed of exposure discovery: they surfaced climate-risk exposure roughly nine times faster than their legacy GIS workflow, because flood-layer and heat-island data could be overlaid against the permit registry in a single query rather than a manual join.

The obstacles that nearly killed it

• Identifier drift. Asset registries and permit systems used different keys. Manual mapping was unavoidable and cost six weeks.
• Ownership anxiety. The fix was not technical. Publishing the weighting formula and version history defused most of it.
• Streaming reliability. Two sensors dropped out for eleven days in May. The team added a staleness flag to every layer rather than hiding gaps.
• Skills gap. Only two staff could write spatial queries at the start. By September, seven could.

What actually changed

The headline number is the planning cycle: 41% shorter, measured against the prior year. The second number is the one the climate office cares about: 9x faster exposure discovery. Neither came from a single feature. They came from collapsing five fragmented streams into one query layer and then resisting the temptation to over-govern it.

What we found most instructive was the connector story. The city did not start from a blank slate; it plugged into systems it already ran. That is the practical appeal of an open API with pre-built connectors to ERPs, asset registries, and SCADA systems. The integration surface is where these projects live or die, not the map rendering.

One caveat for anyone planning something similar: this was not a lift-and-shift. The first six weeks were unglamorous data archaeology. Budget for it, or the project will stall the way the first two attempts did.

The reader's summary was blunt and, we think, correct: "The technology was never the bottleneck. The bottleneck was agreeing on one number." Once the city agreed on one number, the rest moved fast.

If you are weighing a similar consolidation, the sequence that worked here was: map identifiers first, publish your weightings, connect live feeds before historical ones, and measure cycle time from day one. Everything else is negotiation.