Product Development
Findora: Building Software for a Verified Community
Overview
Findora is a lost-and-found platform built specifically for the IIT Madras BS Degree student community. It replaces the informal system most campus communities default to -- scattered WhatsApp groups, Telegram groups, and community channels -- with one verified, searchable, centralized system. See the full product page for the live link and feature list.
The problem
Before Findora, students reported and tracked lost and found items entirely through group chats. That created three specific failures: reports got buried in chat history almost immediately, there was no reliable way to verify that someone claiming an item was actually its owner, and there was no centralized place to search what had already been found. A chat group is a reasonable way to broadcast a message once; it's a poor system of record for anything that needs to be searchable or verifiable later.
The solution
Findora gives the community a dedicated platform to report lost items, post found items, and manage claims through a structured, verified workflow. Two specific design choices do most of the work here: accounts are verified through IITM-linked Google sign-in, so "is this person really a student here" stops being an open question, and owners and finders communicate through private in-app messaging rather than exchanging phone numbers directly.
Architecture
Findora is built on Next.js, TypeScript, Tailwind CSS, and Supabase, deployed on Vercel. Supabase backs authentication, the claims-and-messaging data model, and admin moderation -- the same default stack used across the rest of the company's work, for the same reasons described in why we chose this stack.
Challenges
A few problems are specific to this kind of platform and don't have an obvious off-the-shelf answer. Verifying that someone claiming a found item is genuinely its owner, without making the claims process so strict that real owners get rejected, is a real design tension, not a solved problem. Moderation has to stay manageable as report volume grows, rather than requiring linearly more admin attention. And because most students use the platform from their phones, the report-to-recovery flow has to work well on mobile specifically, not just function on a small screen.
Impact
Findora is in active use by the IITM BS Degree student community, including at campus events such as Paradox, where lost-and-found volume concentrates sharply for a short period. That's the actual measure of whether the verification-and-search model holds up: a system built for everyday low-volume use is tested hardest in exactly these short, high-volume windows.
We're not publishing a Decisions, Tradeoffs, and Lessons Learned breakdown for this one yet -- that's a deliberate choice to wait until there's more to say honestly, rather than write something that sounds like engineering reflection without being one. Visit Findora directly, or see the full product page.