Inspiration
What happens when a relief team pays for twelve hygiene kits and only eight arrive?
That question became the starting point for ReliefOps. A coordinator has to find a supplier who can deliver the remaining kits on time, work out which grant can pay for them, and keep track of what happened to the original order. Each decision depends on information that might be scattered across grant documents, supplier messages, and payment records. I wanted to put those decisions in one workspace.
What it does
ReliefOps helps disaster relief teams turn household needs, supplier quotes, and grant restrictions into a purchasing plan. The coordinator can describe the operation in chat or enter the details manually. AI drafts the inputs and highlights evidence from grant documents and supplier updates. The coordinator reviews those suggestions before applying them.
The planner checks supplier stock, delivery deadlines, and which funds can pay for each item. The coordinator approves the plan, pays through PayPal Sandbox, and records what physically arrives. If an order falls short, ReliefOps checks backup offers, shows any funding gap, and links the replacement purchase to the original order.
In the fictional Pinebrook demo, a team pays $60 for twelve hygiene kits. Eight arrive. A backup supplier can deliver the missing four for $36, but the original order used the full hygiene grant. ReliefOps shows the gap. Once the coordinator records an approved grant increase, the team can buy the four replacement kits and track delivery until all twelve households are covered.
How I built it
I built ReliefOps solo with React and TypeScript on the frontend, FastAPI in Python on the backend, and Supabase for authentication and storage. I deployed the app on Render.
I used GPT-OSS-120B through Groq to turn chat messages and documents into structured proposals. The backend checks that evidence quotes appear in the source and calculates the purchasing plan from reviewed inputs. I integrated PayPal Sandbox for checkout and payment confirmation, and added a PDF export that ties purchases to their funding and delivery records.
Challenges and what I learned
One of the most useful bugs I hit was the AI reading “twelve kits total” as “twelve kits per household.” For twelve households, that changes the order from twelve kits to 144. It taught me to make the quantities easy to review and to keep the purchasing calculations separate from the AI’s interpretation.
I also learned that payment and delivery need their own records. A successful checkout can coexist with a missing shipment. Keeping those states separate made it possible to show what was paid for, what actually arrived, and what the team still needed to buy.
What’s next
I’d like to test the workflow with relief coordinators and their actual grant and supplier documents. I’d also add partial refund reconciliation so that, when PayPal confirms a refund, the team can see how much is available to reuse under the original grant rules.
Built With
- docker
- fastapi
- gpt-oss-120b
- groq
- paypal-sandbox
- postgresql
- python
- react
- render
- supabase
- typescript
- vite
