VenaVena

When blood is needed, the process is still run by hand: a relative posts on social media, the request lands in messaging groups, a phone chain starts. None of it is verifiable, and it puts the heaviest coordination load on the person least able to carry it at that moment. The institutional side is symmetrical: blood supply is a critical operation, but in most places it is tracked reactively, so a shortage only becomes visible once it is already a shortage.

That is what we started Vena for. The goal is not to replace the institutions that already supply blood; it is to build the complementary layer that brings those institutions, hospitals, companies and individuals into one structure.

Matching is a ranking problem, not a lookup. The system finds a suitable donor through multi-factor scoring rather than a single criterion: blood-type compatibility, GPS distance to the hospital, the eligibility window that follows from the last donation date, and donation history. What comes out is a donor list ordered by priority on the hospital side: not "who is eligible" but "who should be asked first".

• Server-first architecture on the Next.js App Router; business logic lives in a service layer, not inside route handlers
• Three separate user paths: the donor application, the hospital panel and operations management
• Supabase Postgres with row-level security policies; the service role is server-side only
• Every API input is schema-validated, then passed through session and role checks
• Location and distance handled through Mapbox, with location permission and manual location managed separately
• A personal-health module that runs from uploading a lab PDF through to reading the analysis
• Dark and light themes, Turkish and English interface

Most of what the platform handles is special-category personal data: blood type, donation history, lab results, latitude and longitude. So authorisation was not added to the data model afterwards; it sits at the database level as row-level policy, and a user's health data is closed by default: reaching it from a company, a hospital or another user requires a policy that explicitly opens it. Location is processed only with permission and only for the matching calculation.

The MVP is complete and running at www.vena.org.tr. The project is in pre-PoC validation: the core flows are being tested against real usage, the hospital-side stock module is being taken beyond prototype, and preparation for institutional partnerships is under way. The product stands up; the next question is validation rather than scale.