Foundly

Inspiration Lost & found systems are often slow, manual, and vulnerable to false claims because people can browse item lists and “guess” ownership. Foundly was inspired by the need for a privacy-first way to reunite people with their belongings while keeping the inventory secure and reducing staff workload. What it does Foundly (Code-carats) — Lost & Found Item Matcher lets users submit lost-item inquiries without ever seeing the inventory. The backend compares each inquiry against a private database of found items and only surfaces high-confidence matches to authorized assistants. User side Submit a lost item using a text description (and optional photo) Track inquiry status (submitted → pending review → approved/rejected) Inventory stays invisible (privacy-first) Assistant side Add found items (text + optional photo) into the private inventory Review high-confidence matches only Approve or reject matches (approve generates a claim code) How we built it Frontend: HTML / CSS / JavaScript Pages for user submission + status tracking Admin pages for adding found items, viewing matches, and managing inventory Backend: Node.js + Express REST API endpoints for user inquiries and admin actions File-based storage using JSON for a lightweight hackathon setup Project structure src/Frontend/ (e.g., admin-add-found.html, admin-add-found.js, check-status.js, lost-report.js) src/backend/ (e.g., server.js, matcher.js, plus auth + db utilities) Challenges we ran into Privacy vs usability: returning enough status information to users while never exposing inventory details. Matching quality: designing a scoring method that handles vague descriptions, inconsistent wording, and partial info. Admin gating: ensuring only authenticated assistants can access inventory and match review actions. Hackathon constraints: keeping it simple and reliable under limited time (file storage, minimal auth, quick iteration). Accomplishments that we're proud of A working end-to-end flow where users submit and track inquiries without seeing the private inventory. Assistants only see high-confidence matches, reducing noise and manual checking. A clean, understandable architecture with clear separation: User flow vs admin flow Frontend UI vs backend API Matching logic isolated in matcher.js What we learned Small UX choices matter a lot when privacy is a requirement (what you show users, when, and why). Even a simple matching algorithm becomes more effective with: consistent normalization, weighted scoring, confidence thresholds. Clear API boundaries and modular files (server.js, matcher.js, db.js, auth.js) speed up collaboration. What’s next for Foundly Improve matching better text similarity (tokenization, synonyms, fuzzy matching) image-assisted matching (optional) per-category weighting (e.g., keys vs electronics) Better data & security move from JSON files to a real database (SQLite/Postgres) proper authentication + role management audit logs for admin actions Product polish notifications when status changes better admin dashboard analytics (match rates, common categories) deployment (hosted backend + simple frontend hosting)