Inspiration
One of our teammates had a friend who needed an organ transplant. We learned from him that one of the most difficult parts of this process is finding a match. We were deeply moved by the struggles it took to find a donor. By doing some research in this area, we also learned that every hour matters when someone is waiting for a life-saving transplant. We thought of using technology as a “clone” seeker, where we wanted to reduce friction and make the first steps toward matching more accessible.
What it does
FindMyDoner is a web app that connects potential donors and recipients through profile-driven organ matching. Users can create an account, sign in, and maintain a dashboard with their personal and medical details relevant to matching. Donors can register organs, and recipients can search for potential matches by organ type and compatibility inputs such as blood type, plus organ-specific criteria like HLA for kidney and pTLC for lung. The app returns match cards with contact details and organ metadata so users can make informed outreach decisions. When a user selects a match, the platform can trigger an email notification to start communication and also track the request in the system. In short, it turns a complicated process into a guided digital flow from onboarding to contact.
How we built it
We built FindMyDoner with a Node.js and Express backend, paired with a static HTML, CSS, and JavaScript frontend for a lightweight and fast experience. The backend serves page routes, processes account creation and login requests, handles organ registration, and runs matching queries based on organ-specific compatibility logic. For data storage, we used a serverless PostgreSQL setup through Neon and organized records by users and organ categories so the matching layer stays clear and extensible. On the frontend, we used dynamic form rendering so each organ type presents only the fields needed for that specific medical context. We also used browser session storage to preserve user state across core pages like registration, matching, and dashboard. For outreach, we integrated email notifications with Nodemailer so users can contact a potential match directly from the results flow.
Challenges we ran into
One major challenge was balancing flexibility and validation across multiple organ types, since each has different matching requirements and required fields. Keeping frontend form behavior perfectly aligned with backend validation rules took careful iteration, especially when field names and payload expectations needed to stay consistent. Another challenge was creating smooth dynamic interfaces without introducing brittle event handling bugs when forms are rendered on the fly. We also had to think through route naming consistency and compatibility aliases so user flows kept working even when different URL styles were used. On top of that, integrating email notifications reliably in development required environmental setup and robust error handling to avoid failed user actions. Finally, representing request history and contact intent in a useful way on the dashboard required thoughtful data shaping so users can understand who requested what.
Accomplishments that we're proud of
We are proud that the app supports a complete end-to-end flow instead of just a mock UI: users can onboard, register, search, and initiate contact in one product. We are also proud of the organ-aware matching logic, because it reflects real compatibility dimensions instead of treating every search the same way. The dashboard experience is another win, since it gives users visibility into their profile, registrations, and request activity in one place. We are especially happy that we implemented contact initiation directly from match results, making the product actionable rather than informational only. From an engineering perspective, we are proud that the architecture is modular enough to extend with additional matching factors and workflows. Most importantly, we built something that feels purpose-driven and not just technically functional.
What we learned
We learned that healthcare-oriented workflows demand both empathy and strict data discipline. Small inconsistencies in field naming, validation, or form timing can break trust quickly in a product where users are already stressed. We also learned the value of separating shared logic from organ-specific logic early, which made the code easier to reason about and adapt. Building dynamic UI taught us to be careful with event attachment and lifecycle timing when content is generated at runtime. We gained practical experience integrating a serverless database, structuring API responses so frontend pages can render richer, more meaningful views, and configuring an email system via Nodemailer to provide real-time updates about potential matches. Overall, we learned that building for a high-stakes domain means designing for clarity, safety, and momentum at every step.
What's next for FindMyDoner
Next, we plan to strengthen security and identity by adding proper authentication, password hashing, and role-aware access controls. Instead of just using a basic blood-type, HLA, size, and plTC filter to determine matchability, we will incorporate many more features including molecular mismatch analysis (epilets), donor-specific antibody (DSA) strength (MFI), and predicted graft survival scores (such as KDPI/EPTS). We also plan to improve communication workflows with richer notifications, clearer request states, and confirmation steps that reduce accidental outreach. Another priority is adding better clinical context and disclaimers so users understand that the app supports discovery but does not replace medical evaluation. We aim to expand geographic filtering and interoperability so matching can scale across regions and institutions. This can be done by utilizing the Google Maps API to render maps of where potential matches would be located. In the long term, we want FindMyDoner to evolve from a matching prototype into a trusted coordination platform that helps more people find timely transplant pathways.
Note: we used AI for doing quite a bit of the CSS of the project, along with debugging simple bugs along the way.
Built With
- css3
- express.js
- gmail
- html5
- javascript
- neon
- node.js
- nodemailer
- sql
Log in or sign up for Devpost to join the conversation.