Most software stops at the screen. This one has to open a door.
The platform lets a community share resources — people list what they have, others claim it, and a wall of lockers handles the handover so nobody has to be in the same place at the same time. That last part is the hard part: the moment software is responsible for a physical door, "it worked on my machine" stops being good enough.
The control plane
Each locker site runs a small computer that owns the doors. The platform assigns a door, then sends a signed open command over a private network — every request carries a timestamp and a signature the device verifies before it moves anything. An unsigned or replayed request opens nothing.
Doors are optimistically marked open the moment the command is accepted, then reconciled against the hardware's own reported state by a scheduled job. The two disagreeing is not an edge case — it is the normal condition of anything mechanical, and the system is built to notice rather than assume.
Each site pulls its full configuration from the platform as a structured tree that maps one-to-one onto the local database on the device. Changing how a site behaves is a data change, not a site visit.
When something goes wrong
A door that reports itself open for too long raises a stuck-door alert. Temperature outside the expected range raises another. Both matter, because the lockers hold things people are relying on — and a failure nobody is told about is worse than a failure.
Beyond the mechanics, each door carries addressable lighting and a text display, both driven from the platform, so the wall can guide someone to the right door without an attendant standing next to it.
The rest of the system
The public side is a single codebase that ships as a website and as native iOS and Android apps. Notifications go out over push and SMS, with more than one SMS provider configured so a single vendor outage doesn't silence the system.
Members can link an account from a local community-currency scheme through a standards-based sign-in flow, with the tokens held and encrypted server-side rather than handed to the browser. Listings are searchable geographically, and events from an external ticketing platform are pulled in automatically on a schedule and de-duplicated on the way through.
Why this one matters
This is a five-year relationship, still shipping. The interesting engineering is not any single feature — it is that the same system has to be correct for a database row and for a steel door, and only one of those can be rolled back.
In the client's words
Both long-running contracts behind this platform closed in October 2026 with five-star feedback on Upwork. The client wrote, of the backend and server work:
"Dhaval is an exceptional developer and a pleasure to work with. He communicates clearly, thinks carefully, and brings real depth to complex technical challenges. His strength lies in bridging different technologies and domains, connecting the pieces of a system in ways that make difficult problems manageable. He's become a trusted part of our team."
And of the Flutter front end that runs on the kiosks:
"Working with Dhaval has been a fantastic experience. He's a highly skilled developer and an excellent communicator who keeps you informed and makes collaboration easy. What sets him apart is his ability to work across disciplines: he understands how the front end fits into the larger system, which lets him solve problems at their root rather than just at the surface. Highly recommended."
Both quotes are verbatim from the public Upwork profile, October 2026.