Every space accounted for.
Occupancy, vehicle movement, access and billing digitised end to end. Live in Motijheel, Dhaka, with Dhaka South City Corporation.
A cash business run on paper
Kerbside parking in a busy commercial district is a cash business run on paper. Nobody can say how many spaces are occupied at eleven in the morning, which means nobody can say how many should have been paid for. The gap between those two numbers is not a rounding error, and it is invisible until something starts recording it.
That is the problem a parking system actually solves. Not convenience. Visibility.
What it does at the kerb
Occupancy, vehicle movement, access and billing, digitised end to end, with real-time space utilisation and a live record of the district.
It had to work with the access control and payment hardware already on site. A parking system that needs the barrier replaced first is not a parking system, it is a second project.
What it does today.
Everything listed is something the software does now. Nothing on this page is a roadmap item, and there is no roadmap on it either.
Occupancy
Space utilisation as a live figure rather than a monthly estimate.
Vehicle movement
Entry and exit recorded as events at the moment they happen, so the record is built by the operation rather than after it.
Access workflows
Integrated with the barriers and controls already installed, not dependent on replacing them.
Billing and collection
Collection digitised through the payment infrastructure the authority already operates.
Real-time monitoring
The district as it is, not as it was at the last count.
Operational reporting
The record an authority can be asked about, produced as the work happens.
How it is put together.
The failure this system addresses is a missing link in a chain: three things happen at the kerb and the fourth, a record, never does. The architecture exists to close that chain at the moment the event happens rather than to reconstruct it afterwards.
Peak is eight in the morning. Correctness at the busiest hour is the acceptance condition, because that is the hour a manual process is least able to cover for the software.
What actually gets attacked.
A municipal system produces a record that may end up in a public account, so integrity and auditability come before confidentiality: what happened, when, at which point, and who could have changed it afterwards. Payment runs through infrastructure the authority already operates rather than through anything we introduce.
Ownership, handover and AI governance covers what a procurement or security reviewer usually asks next.
Why there is no figure here.
No revenue, collection-rate or bay-count figure appears here. Those are Dhaka South City Corporation’s numbers to publish rather than ours, and nobody has asked them for one. If they share one it goes on the case study with its method and its date beside it.
Technology
- Backend
- PythonDjangoFastAPINode.js
- AI
- LLMsRetrieval augmented generationComputer visionMachine learning
- Data
- PostgreSQLMySQLRedisData modelling
- Cloud
- AWSDockerCI/CDInfrastructure as code
Questions we get asked.
What buyers of this platform ask before a demo.
Do we need to replace our barriers and payment equipment?
No. Integration with what is already installed was a precondition of the Motijheel design rather than a phase of it, and a system that requires a hardware replacement first is not solving the problem you have.
Who is it running for?
Dhaka South City Corporation, in Motijheel, named here with their written permission.
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