Municipal systems that work at eight in the morning.
Operations digitised end to end, integrated with the hardware already installed on site, and judged at the hour a manual process is least able to cover for them.
What is hard about this sector, before anybody writes software.
If a line below would still be true had we never worked in this sector, it is not specific enough to be on the page.
The record does not exist
A cash operation run on paper cannot say what was occupied at eleven in the morning, so it cannot say what should have been paid for.
The hardware is already there
Barriers, controls and payment equipment were chosen before the software and are not ours to replace.
Peak is the acceptance test
Off-peak correctness is easy. The system is judged at the hour when arrivals outrun anybody’s ability to write them down.
Public accountability
A municipal system is answerable in a way a private one is not, and the record it produces has to hold up to that.
Capabilities, in the order they matter.
Municipal operations digitised end to end, working with the access control and payment hardware already installed on site.
End-to-end digitisation
The whole operation, not a paper process with a screen at the end of it.
Real-time occupancy
Utilisation as a live figure rather than a monthly estimate.
Vehicle and access workflows
Entry and exit recorded as events, integrated with the access control already on site.
Billing and collection
Collection digitised through the payment infrastructure the authority already operates.
Operational monitoring
The district as it is, not as it was at the last count.
Peak-hour correctness
Designed and accepted against the busiest hour rather than the average one.
Systems running in this sector.
Derived from the engagement record, so this section cannot list work that is not in it.
What changes about security in this sector.
A municipal system produces a record that may end up in a public account, so the requirement is integrity and auditability before confidentiality: what happened, when, at which point, and who could have changed it afterwards. Payment paths run through the infrastructure the authority already operates rather than through anything we introduce.
DevTechGuru holds no security or industry certification, and no page on this site claims one. Where a regime applies it is named as your obligation and as a design constraint we build inside. Ownership, handover and AI governance covers what a procurement reviewer usually asks next.
Technology
- Backend
- PythonDjangoFastAPINode.js
- AI
- LLMsRetrieval augmented generationComputer visionMachine learning
- Data
- PostgreSQLMySQLRedisData modelling
- Cloud
- AWSDockerCI/CDInfrastructure as code
Questions we get asked.
Questions this sector asks that the others do not.
Do we have to replace our existing equipment?
No, and a system that requires it is not solving the problem you have. Integration with the access control and payment hardware already installed was a precondition of the Motijheel design, not a phase of it.
Can you name the authority you worked with?
Yes. Dhaka South City Corporation, named here with their written permission. They are the only client named on an industry page; three others have cleared us to use their name on their own case studies.
Where to go next
You do not need to arrive with a perfect technical specification.
Start with the problem. Tell us what is slowing the business down, what you want to build, or where the current system is failing. We will tell you the shortest path forward, including when that path is not us.
Start your build