GeoBlood
A blood request should reach the right nearby donor in seconds, not after a night of phone calls.
request · locating donors
click the map to post a requestThe problem
GeoBlood exists because of a family medical emergency where finding a matching blood donor took dangerously long. That search is normally a chain of phone calls, WhatsApp forwards and hospital noticeboards. It is slow, it leaks personal numbers, and none of it is verified. The organisation's stated mission is blunt: no one should lose their life due to lack of blood availability.
The engineering problem underneath that is a matching problem with a hard deadline. A request has to reach donors who are actually compatible, actually nearby, and actually real, and it has to do that while the requester is standing in a hospital corridor.
The value I added
- Turned an ad-hoc phone-call process into a structured request that resolves in the app: post a need, get matched, coordinate, done.
- Shipped and maintain the native iOS app in Swift, and contributed to the Android app, so the platform reaches donors on whatever phone they own.
- Built the backend so a nonprofit with no ops budget runs on infrastructure that scales with donations, not with headcount.
- Made privacy structural rather than a policy line: donors and recipients coordinate without ever exchanging phone numbers.
how the match works
three filters, one orderingA blood request is not a broadcast. Spamming every user in a city destroys trust and gets the notification permission revoked within a week. So the match narrows before it notifies.
1. Compatibility
Blood type is a directed graph, not an equality check
O negative can give to anyone. Everyone else cannot. The rule lives in one place on the server.
2. Proximity
Geospatial query, not a city string
Distance is computed, indexed and sorted server-side so the nearest eligible donor is first, not alphabetical.
3. Verification
Unverified accounts never enter the pool
Verification is checked at match time, so an account that lapses drops out immediately.
4. Urgency
Not every request is equal
Critical requests get a higher push tier and a wider radius. Routine ones do not wake anyone up.
5. Coordination
Contact details never change hands
Encrypted in-app messaging plus emergency calling, with no phone number exposed on either side.
what I built
| Layer | Built with | What it has to survive |
|---|---|---|
| iOS app | Swift, MVVM | App Store review cycles, Sign in with Apple requirements, permission prompts the user can deny, and a phone that is asleep when the notification arrives. |
| Android app | Java, Kotlin | Fragmented devices and aggressive OEM battery managers that kill background delivery. |
| API layer | Node.js, Express | Matching, request workflow, auth and admin operations under bursty traffic when a request goes out. |
| Data | MongoDB, Redis | Geospatial queries fast enough to run inside a request, with Redis absorbing the repeated reads. |
| Real time | Socket.IO | Chat and live request status across reconnects, backgrounding and flaky mobile networks. |
| Push | FCM, APNs | Two delivery systems with different failure modes, retried per-platform and never silently dropped. |
| Auth | Apple, Google, JWT | Account recovery and session integrity across two platforms and a web dashboard. |
| Admin | React | Verification queue, request moderation and platform data, used by volunteers rather than engineers. |
| Infra | AWS, Firebase | A nonprofit budget. Sized for the load it has, with headroom for the country it launches in next. |
see it running
from the GeoBlood teamGeoBlood on Instagram
Tap to load the reel from @geobloodorg
Loads directly from Instagram. Nothing is requested until you click.
Or open it on Instagram directly ↗
the app
click any shot to enlarge
why it is robust
the honest versionA blood app that is down is worse than no blood app, because someone was relying on it.
- Push is never assumed delivered. FCM and APNs both fail in their own ways. Request state lives on the server, so opening the app shows the truth even if every notification was dropped.
- Verification is checked at match time. Enforcing it only at signup means a revoked account keeps receiving requests forever. Filtering at query time makes revocation instant.
- Geospatial work happens in the database. Pulling donors into the app to sort by distance does not survive a real user base. The index does the work.
- Redis absorbs the read burst. When a request goes out, the same donor set gets read repeatedly. Caching that is the difference between a responsive map and a spinning one.
- App Store compliance is designed in, not patched. Health-adjacent apps get scrutinised. Sign in with Apple, clear permission rationale and data handling were built in from the first submission.
- What I would revisit: the matching radius is currently tuned per country by hand. It should adapt to donor density, so a dense city narrows and a sparse region widens automatically.
writing
on HackerNoonI wrote up the geospatial matching design in more depth: Matching Blood Donors by GPS: The Geospatial Query Design Behind GeoBlood ↗
Want the architecture walkthrough?
Happy to go through the matching model, the push reliability design or the App Store compliance path on a call.