Reclaim: Helping cleanup materials reach someone who needs them
Reclaim connects people offering materials from events and cleanups with those who need them. This article explains photo-assisted listings with Amazon Bedrock, private storage in S3, and the workflow from request to completed handover.
After a cleanup event, organisers can be left with materials that someone could still use. Wood might be useful for a project. Cardboard could be used for packaging, and pots could find a place in someone's garden. Once those materials are collected, how do they reach the person who needs them?
Finding that person takes work. An organiser has to explain what is available, find interested people and arrange collection. Someone looking for those materials may never hear about them. Even an item offered for free needs a way to be found and picked up.
That is the problem I wanted to work on: helping people offer reusable materials from cleanup events and helping others find them. Depending on the item's condition and value, the organiser could sell it or give it away.
I also saw students cleaning up after a protest, taking responsibility for the space they had used. It made me think about the same question: what happens to the useful materials once the cleanup is over?
During Environmental Hacks, I built Reclaim to make those exchanges easier. People can offer materials from events and cleanups, request what they need and agree on a handover.
How Reclaim works
Reclaim lets people offer reusable materials and sorted recyclables for free or for a price, depending on their condition and value. The same account can buy and sell.
A seller adds photos, describes the material and its quantity, and provides pickup information. Visitors can explore the board and read item details without signing in. They need an account when they want to send a request.
The exchange follows a few steps:
- The buyer finds an item and proposes a pickup time.
- The seller reviews the request and accepts or declines it.
- After acceptance, both people can see each other's contact details.
- They arrange collection directly.
- After pickup, the seller marks the handover complete.
I wanted the record to continue beyond the listing. Both participants keep the completed exchange in their history, and their profiles show completed handover counts. Someone reviewing a request can look at that history before deciding. It gives them context, although it cannot guarantee how the next exchange will go.
The architecture follows the handover
The backend controls publication, requests and the changes that follow acceptance. Photo analysis is an optional part of preparing a listing. It returns suggestions for the seller to review; it has no authority to publish an item or accept a buyer's request.
Responsibility | Implementation |
|---|---|
Listings, discovery, profiles and handover screens | Next.js and React |
API fetching and cached data | TanStack Query |
Client state | Zustand |
Authentication, validation and marketplace rules | TypeScript backend |
Users, items, requests, handovers and notifications | PostgreSQL |
Listing photos | Amazon S3 |
Suggestions from photos | Kimi K2.5 on Amazon Bedrock |
Temporary email-verification codes | Redis |
Email delivery | Transactional outbox with Nodemailer SMTP |
PostgreSQL stores items and their requests together with the handover records. When a seller accepts a request or completes a collection, the backend updates the related records within a transaction. That keeps the item's status consistent with the agreement.
Photos take a separate path. The backend validates and processes each upload, then stores the image in a private S3 bucket. PostgreSQL holds its ownership and object key. When the seller asks for suggestions, the backend retrieves the image and sends it to Kimi through Bedrock.
Notifications are recorded alongside marketplace changes. An outbox worker delivers email afterward, so email delivery does not have to finish before the marketplace operation can succeed. The active provider is Nodemailer SMTP, with SES available through a configuration switch.
Turning a cleanup photo into editable listings
Writing several listings after a cleanup can take time. A seller can start with a photo and select Find items in photo.
The backend makes one request to the serverless
moonshotai.kimi-k2.5 model on Amazon Bedrock. The prompt asks it to identify visible reusable or recyclable materials and return structured JSON with English names, descriptions, condition notes and possible hazards.The response goes through backend validation before it becomes a set of item drafts. The seller checks the suggestions, corrects anything that is wrong and enters a price before publishing through the normal form.
That review matters. A photo cannot establish a batch's weight, reveal hidden damage or confirm that an item is safe. The prompt tells the model to report uncertainty and avoid inventing those details.
Suggestions also preserve items the seller has already entered manually. If the photo uploads successfully but analysis fails, Keep photo and enter details lets them finish the listing with that image. They do not have to upload it again or make another model call to continue.
A request becomes a collection agreement
The buyer proposes a future pickup time and can leave a note about transport, intended use or a question for the seller. While that request is pending, the item stays available and other buyers can send their own requests.
The seller reviews the proposals and can open each buyer's public profile. Accepting one request reserves the item for that buyer and declines competing pending requests. The backend locks the relevant records and applies the changes in a transaction, preventing two buyers from reserving the same item.
Acceptance also gives the participants a way to connect. Both can see the other's account email and optional mobile number. Someone without a phone number can still arrange collection by email.
Contact details stay off public listings. Only the handover participants get access, and email-verification status is shown separately. Both receive in-app notifications; handover emails go to verified addresses.
They agree on transport and any payment directly. Reclaim records the asking price, but it does not process money or verify that payment took place.
Completion needs its own record
A seller accepting a request does not mean the material has been collected. I kept completion as a separate action so the record reflects what the seller confirms after pickup.
When the seller selects Mark handover complete, the backend completes the handover and marks the item as done in the same transaction. It leaves discovery and the seller's active listings, while both participants retain the exchange record.
That adds one completed offered handover to the seller's history and one completed collected handover to the buyer's history. Publishing an item or accepting a request does not increase either count. Repeated taps and retried completion requests must not count the same exchange twice.
Before completion, either participant can cancel an accepted handover. The reservation is released, the item becomes available again and completed counts remain unchanged.
What changed during the build
Working through the collection flow changed some of my early decisions.
I initially tied collection to a listing window. That was awkward for materials from older events: an item could still be useful long after the event ended. I separated the event date from pickup. The event or cleanup date now gives buyers context about where the material came from. The buyer proposes a time for the new collection, and an old event date does not block publication, requests or completion.
I also made email verification optional at signup. People can create an account and start using Reclaim, then verify from Profile. Redis stores a hash of the six-digit code with a ten-minute expiry. Verification status remains visible to other participants, while unverified accounts can still list materials, request items and complete handovers.
Photo analysis led to a different kind of fix. AWS returned BEDROCK_ACCESS_DENIED, although Reclaim's environment file contained a Bedrock key. The backend was choosing an inherited AWS_BEARER_TOKEN_BEDROCK value before the application's AWS_BEDROCK_API_KEY. The keys were different.
I changed the priority to prefer the application's configured key and added regression coverage for that choice and the fallback alias. A small live Kimi text request then returned HTTP 200 with the expected response. That confirmed access with the selected key; the upload and image-to-listing flow still require their own checks.
Conclusion
I built Reclaim to make it easier for someone with leftover materials to reach someone who needs them. A listing starts that conversation, and the handover flow carries it through collection, leaving both people with a record of the exchange.
Links
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article