PivotingaLegacyCompany

Across hundreds of hours in the field, every role collapsed to the same two things: objects, and tasks performed on them. A meter, a pipe, an inspection, a repair. The work never actually differed by department, only the labels did.

So I refused to build modules. I designed the platform as two primitives, objects and tasks, that any city could compose into any module, each rendered three ways from one source: filterable dataset views, configurable maps, and guided stepper workflows. The cost was that no single module felt as bespoke as a tool built only for it. The return was a platform that grew by configuration instead of engineering, and a single mental model a field worker carried from one module to the next.

The legacy system gave administrators all the control. A field worker couldn't add an asset, change a dashboard, or adjust a workflow without an admin editing a config file first. The limit was never the software's features. It was a person in the middle of every change. In public-sector teams, where headcount never grows, that wasn't inefficiency. It was a structural failure with no staffing fix.

So I moved control to the edge. Field workers and managers configured their own dashboards and pulled assets from a catalog. At the center were guided stepper workflows I designed to walk an untrained worker through specialized tasks one step at a time, so a new hire could do the job correctly with no expert and no admin in the loop. Admins weren't displaced, they were freed from being the dependency everyone queued behind. The trade-off was trust: real configurability invites misconfiguration. In a sector where autonomy was the only thing that scaled, I took that bet.

Before I joined, seven engineers built features with no shared component library. Every screen reinvented its buttons, forms, and spacing, and it showed. I stopped feature work to build the design system first.

Rather than write base components ourselves, I adopted MUI, the open-source Material Design library, so the foundation came with community updates and new components I didn't have to maintain. Migrating the existing screens onto it cost about eight weeks before any return. After that the math inverted: every new module composed from shared components instead of hand-coding its own. The parts MUI never shipped, interactive maps, collaborative dataset views, guided field workflows, I built from MUI primitives, so even the custom surfaces inherited one visual language. That investment bought a platform where each module shipped faster than the last.

Bolting the old platform onto AutoCAD had locked it to a handful of CAD experts; everyone else queued behind them. Web-based maps removed that gate, so the 99% who could never work the system independently finally could. But access couldn't cost us precision.

Engineers construct sewer networks where a slope off by a few millimeters means water pools instead of drains. A web map will never hold that, and without it our customers can't do their job. The easy answer was two separate products. I refused to split the data behind them. AutoCAD stayed the tool for precision construction, web maps served everyone else, and both read from and wrote to one GIS database. An engineer builds to the millimeter in CAD; the same data lands in a single source of truth and renders on the web for the field. Two interfaces, one database, neither compromised.

The pivot proved out

Cities adopted one module, then came back for the next.

The platform's leverage showed clearest in Frankfurt: a workflow that had taken six weeks, automated to under a minute. That solution became its own module, sold to other cities.

I estimated roughly €1M in annual savings per customer, from collapsing software licenses, on-premise data centers, and IT maintenance into one SaaS stack. Beyond cost, field crews traded pen-and-paper documentation and control-room handoffs for guided digital workflows, finishing more work per shift with no added headcount.