About the project

We built OpenClaims Ops because we kept coming back to a simple problem: reimbursements, stipends, and small grant programs are still painfully manual.

In a lot of student organizations, hackathons, nonprofits, and campus programs, the process usually looks the same. Someone posts a form, people upload receipts, and then one organizer ends up digging through spreadsheets, email threads, screenshots, and random PDFs trying to decide what is valid. It is slow, frustrating, and easy to abuse. If the program is open to a large group of people, it becomes even harder, because there is no easy way to know whether each submission is coming from a unique real person.

That is what inspired us to build OpenClaims Ops.

Our idea was to create a system that does more than collect submissions. We wanted to build something that could actually run the whole workflow: verify the claimant, collect the proof, process the document, apply program rules, and route the claim automatically. That is where World ID became especially important. Instead of using proof of personhood like a simple login feature, we made it part of the product’s foundation. In our flow, claimants verify with World ID before they even access the form. That helps enforce one human, one claim, which makes the rest of the automation much more trustworthy.

How we built it

We built OpenClaims Ops as a full-stack web app using Next.js, React, and Supabase for authentication, data storage, and file handling. We designed it around two main experiences:

A public claimant flow, where a user verifies with World ID, uploads a receipt or proof document, and submits a claim
An organizer dashboard, where a program manager can create claim programs, define rules, monitor incoming claims, and review anything flagged by the system

On the processing side, we added document extraction and a rules-based workflow. Once a claim is submitted, the system can pull structured information from the uploaded proof, compare it against the requested amount and program settings, and then decide whether the claim should be approved, rejected, or sent for manual review.

That combination of identity verification, automation, and organizer tooling is what makes the product feel useful beyond a demo. It is not just a concept screen. It behaves like a real operations tool.

What we learned

One of the biggest things we learned is that automation only works if the inputs are trustworthy. That sounds obvious, but it became a huge design insight for us. A lot of tools can automate form processing, but in open applicant pools the real challenge is trust. If you cannot tell whether the same person is submitting multiple claims, then you still end up needing humans to manually review everything. World ID changed that for us by giving the product a reliable identity layer at the front door.

We also learned how much product design matters in hackathon projects. It is easy to build disconnected features, but much harder to create a flow where each part supports the next one. In our case, the public form, the receipt processing, the rules engine, and the review queue all needed to feel like parts of one coherent system.

On the technical side, we learned a lot about integrating identity verification into a live workflow, handling document-based submissions, and designing around exception cases instead of only happy paths.

Challenges we faced

One challenge was making the project feel realistic instead of overpromising. It is easy to say “AI will process claims,” but the harder part is deciding what the system should actually do when confidence is low, when the requested amount does not match the receipt, or when something looks suspicious. We spent time thinking about how to route claims in a way that feels operationally believable.

Another challenge was balancing automation with human review. We did not want the app to act like it could replace human judgment in every situation. Instead, we designed it so the system handles the repetitive first pass, and humans step in only when there is something worth looking at. That felt like a much more practical and honest solution.

We also had to think carefully about how to present World ID in a meaningful way. We did not want it to feel bolted on. The challenge was showing that it is actually central to why the product works, not just a badge on the landing page.

Why we are proud of it

What we are most proud of is that OpenClaims Ops solves a real problem in a way that feels both practical and technically interesting.

It shows how proof of personhood can unlock better workflows, not just better logins. It shows how automation can reduce manual overhead without removing transparency. And it shows how a messy process that usually lives across forms, spreadsheets, and inboxes can become one clean, trackable pipeline.

At a high level, the old process is:

$$ \text{Form} \rightarrow \text{Spreadsheet} \rightarrow \text{Manual Review} \rightarrow \text{Confusion} $$

What we built is:

$$ \text{World ID Verification} \rightarrow \text{Claim Submission} \rightarrow \text{Document Processing} \rightarrow \text{Rules Engine} \rightarrow \text{Review or Resolution} $$

That shift is what OpenClaims Ops is all about.