From Kabadiwala to Responsible Recycling: Building E-Saathi Connect on AWS
What happens to an old phone after we hand it over for scrap? I built e-Saathi Connect to explore how AWS can help track discarded electronics across collectors, hubs and downstream facilities.
How a question about discarded electronics turned into a deployed AWS application, a tamper-evident custody system, and a lesson in debugging beyond the code.
A phone stops working. A laptop gets replaced. An old washing machine finally gives up.
In many Indian neighbourhoods, these things eventually find their way to the local kabadiwala. We hand them over, collect whatever money we can, and move on. I've seen this as an ordinary part of life. What we don't usually see is what happens after the first handover.
Who receives the device next? Where does it eventually go? And if someone wanted to verify its journey, would there be a reliable record to follow?
That was the question I took into AWS Environmental Hacks by Bharat Builds Tour. I decided to build e-Saathi Connect, an e-waste traceability platform designed to connect consumers, local collectors, collection hubs and downstream processing facilities through a shared record of each device's journey.
The idea was easy enough to explain. Building it was a different matter.
The missing link after collection
The problem I wanted to address wasn't that local collectors were doing something wrong. They already play an important role in moving discarded material through the economy. The difficulty is that information can become fragmented as a device changes hands.
A consumer might know who collected an old phone but have no way to follow its journey afterwards. A hub might know what it received without having a consistent record of how the device reached it. A downstream facility might record its own work without that history being connected to the original collection.
Each person may know what happened at their end. The wider journey can still be difficult to reconstruct.
I wanted to see whether software could help connect those separate steps without pretending that a digital record alone guarantees responsible recycling.
That became the starting point for e-Saathi Connect.
The first challenge was deciding what a record actually meant
I didn't want to build a dashboard where users could simply change a device's status and call that traceability.
Imagine a device moving from
COLLECTED to RECEIVED . That transition sounds simple, but who is allowed to make it? Is the device at the right stage? What happens if an older request arrives after a newer update has already been made?These questions shaped the custody engine.
The application uses an explicit transition policy to define how a device moves through states such as
CREATED , HANDED_OVER , COLLECTED , RECEIVED , ASSESSED , ROUTED , PROCESSING , PROCESSED , VERIFIED and CLOSED .The backend checks the actor's role and the current lifecycle state. It also uses an expected record version to reject stale updates instead of silently overwriting newer information.
That distinction matters to me because a convincing interface can make almost any workflow look complete. The backend has to enforce the rules even when a request comes from somewhere other than the expected screen.
When the login screen stopped being a login-screen problem
One of the more frustrating parts of building the application was getting authentication to work in the deployed environment.
The Cognito user and password appeared to be correct, yet the live login flow still wasn't working. My first instinct could have been to keep checking the credentials or changing things in the interface. But that wouldn't explain why the same authentication details weren't producing the expected result.
I had to look beyond the visible login screen and inspect the connection between the frontend and Amazon Cognito. While tracing the client configuration, I found that the authentication-flow information was coming back as
null .That gave me a more specific place to investigate. Instead of treating every failed login as a password problem, I needed to understand what the deployed client was actually configured to request and how that configuration reached the authentication service.
It was a useful reminder that an application can look correct on screen while something important is wrong at the boundary between two services.
This kind of debugging is not particularly glamorous. It involves following the request, checking assumptions and resisting the temptation to change several things at once. But it is part of what separates a locally convincing demonstration from an application that can be tested in its deployed environment.
It also changed how I thought about verification. A successful deployment is not proof that authentication works, just as a successful login is not proof that every downstream workflow works.
Making the custody history tamper-evident
Authentication answers who can access the application. It doesn't answer whether the history recorded by the application can be trusted.
For the custody ledger, I implemented a hash-linked event history using SHA-256.
Each event has a hash derived from its payload. Its event hash also incorporates the preceding event's hash, linking the records into a sequence.
Event 1 → Event 2 → Event 3 → Event 4 If an earlier event is modified, verification should detect an integrity mismatch when the chain is checked. The repository includes a custody-service test that deliberately changes an earlier event's recorded lifecycle state and checks that verification returns an invalid result.
I wanted this to be a behaviour the code could test, rather than a security claim made because the interface displayed an audit history.
There is an important limit, though. Hash chaining can help detect certain changes to recorded events. It cannot prove that a physical handover happened or that the information originally entered was truthful. That requires trustworthy evidence and appropriate checks outside the hash calculation itself.
For a project built around accountability, I think being precise about that limitation is just as important as implementing the mechanism.
Why a photograph needs more than a status label
A custody event and a photograph supporting that event are two different things.
The event records structured information about a transition. The photograph provides supporting material that may help someone review it. They need to be connected, but they should not be treated as interchangeable.
In e-Saathi Connect, Amazon DynamoDB stores device and workflow records, while Amazon S3 stores evidence files. The repository documents an evidence workflow with upload intent, upload-completion checks and controlled access to stored objects.
This separation gives the application a clearer way to manage operational records and supporting files.
It also prevents an easy mistake in how the product is described. A photograph may support a handover record, but it doesn't automatically prove that a device reached an authorised recycling facility or that its data was securely sanitised. Those outcomes need their own verification.
The goal is to make the journey easier to inspect, not to claim that software can replace every real-world check.
Putting the application on AWS
I built the frontend using React and TypeScript, with AWS managed services supporting the backend and deployment.
Amazon CloudFront delivers the web application, with static assets stored in Amazon S3. Amazon Cognito supports authentication, Amazon API Gateway exposes the backend API, and AWS Lambda runs the application logic. Amazon DynamoDB stores device and workflow records, while S3 also holds the supporting evidence. I used AWS Cloud Development Kit (CDK) to define the infrastructure as code.
The main request path is:
Web application → API Gateway → Lambda → DynamoDB and S3
The architecture is only useful if the application logic behind it behaves correctly. Authentication needs to work in the deployed environment. Lifecycle rules need to be enforced by the backend. Custody events need to remain associated with the right device, and evidence needs appropriate access controls.
The public repository includes tests for initial custody transitions, invalid role transitions, stale-version conflicts and tampered-event detection. It also contains a CI workflow configured for formatting, linting, type checks, tests and CDK synthesis.
I have documented a future direction for event-driven integration using DynamoDB Streams and Amazon EventBridge, but I am not presenting that downstream pipeline as fully operational in the current build.
I wanted to build on AWS in a way that could support further development, while being honest about what is implemented today.
What the prototype proves, and what it doesn't
e-Saathi Connect has a deployed web application, role-specific workspaces, device registration, custody workflows, evidence handling and an administrative audit view. The public repository includes screenshots showing parts of the application and a test device moving through the recorded workflow.
That is something concrete to inspect. It is not proof that a physical device has reached an authorised facility or that the platform has improved recycling outcomes.
Those questions require a real pilot with collectors, hubs and verified downstream facilities. We would need to learn whether the workflow is practical for the people doing the work, whether records remain consistent across handovers and whether facilities can reliably report what happens to the devices they receive.
Security review, operational monitoring, privacy and retention policies, and comprehensive end-to-end testing are also necessary before treating the application as production-ready.
I see those as the next stage of the work, not achievements to claim before the evidence exists.
What I want to take forward
Building e-Saathi Connect brought together two things that are easy to underestimate: the complexity of a real-world problem and the amount of work hidden behind a working application.
A device changing hands is easy to represent as a status update. Making that update meaningful requires lifecycle rules, access controls, a history that can be checked and evidence that can be reviewed. Getting the services connected is only one part of the job. Testing their behaviour in the deployed application is another.
The prototype gives me a foundation to explore those questions further. The next step is to test it with the people who actually collect, handle and process discarded electronics, and find out which parts of the workflow hold up outside a demonstration.
I started with a question about what happens to an old phone after we hand it over. I haven't solved the wider e-waste problem, and I don't want to claim that I have.
But I have built something that lets me explore how its journey could be recorded, followed and reviewed more consistently.
For me, that is a useful place to start.
Project: e-Saathi Connect
Built for: AWS Environmental Hacks by Bharat Builds Tour
Technology: React, TypeScript, Amazon Cognito, Amazon API Gateway, AWS Lambda, Amazon DynamoDB, Amazon S3, Amazon CloudFront and AWS CDK
Disclosure: AI-assisted development tools were used during this project. The article distinguishes implemented functionality from planned integrations and outcomes that still require real-world validation.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article