The problem
A broken street lamp reaches a town hall as a phone call, a counter visit, a Facebook comment and an email — four channels, no shared list, no clock running on any of them. Nobody can say how many problems are open, which are late, or whether the crew sent last week actually fixed anything. The resident finds out by walking past.
What we built
One system for the whole loop. Residents report a problem from a phone — category, map pin, photo. Staff triage it, assign a crew and a deadline. The crew closes it with a photographed work report, and the resident who reported it confirms it or sends it back. Every request carries a visible chain of states: under consideration, in progress, waiting for approval, agreed.
CUBA Platform (today Jmix) · Java · PostgreSQL · native mobile
Why it is the case we show first
It answers the two objections we hear most about this technology stack at once. “Can you really build something complex on it?” — a public-sector system with a web portal and a mobile app on one core, a full request lifecycle and an administration serving around 80,000 residents behind it. “Won’t it look like an internal admin panel?” — the screens below are the shipped product.
And it is the long answer to “how long have you worked with Jmix”. We built this on CUBA Platform — the framework that became Jmix — years before the rename. The migration path from one to the other is not a slide for us; it is a route we have walked with our own production code.
Multi-comune from the first release: categories, crews, deadlines and branding are configuration, not a fork. Adding the next administration is a setup task.
- Residents served
- ~80,000
- What we built
- portal + app one core, two clients
- Request categories
- 12
- Sign-off on every job
- the resident
- Average time to close
- 5 days
- In production since
- 2020
“People can finally tell that the town hall is listening.”
