Case studies / Blood-donation coordination
Hayah
A clearer path from a blood request to a donor.
A mobile experience for donors and requesters, backed by a web-based staff console and an API for blood-donation workflows in Jordan.
Explore the project

Local demo
- Designed & developed by
- Mohammad Shams
- Contribution
- End-to-end design and development
- Core technologies
- Flutter
- Next.js
- PostgreSQL
Founder-owned portfolio project; not presented as a Teqaniyah client engagement.
Local demo
Inside the product
Captured from locally running applications with fictional demo data. Names, requests, prices, and dashboard counts are examples—not customer records or business results.
Overview
Blood requests carry several kinds of information at once: blood type, location, urgency, and the time help is needed. The product brings these details into a request-led experience, with separate workflows for people requesting help, donors responding, and staff reviewing requests.
The software needs to distinguish a request from a donor’s offer to help. Staff review, request status, and claim status are separate concerns—not one “donate” button.
Hayah brings the mobile app, API, and staff console together as one project, with a separate experience for each role.
The user journey
Create a request
A requester supplies the blood type, governorate, urgency, and needed-by date. New requests enter a review state.
Review and publish
Authorized staff can approve or reject pending requests. The backend checks the request’s current state before allowing a transition.
Respond and track
Available donors can offer to help with open requests. Claims have their own lifecycle, distinct from whether the request is open or fulfilled.
What was built
Flutter mobile experience
Mobile feature areas cover onboarding, authentication, request creation and browsing, request details, donor claims, and profiles.
Staff operations
A separate web console supports request review, urgency updates, user management, and staff invitations, with permissions for administrative roles.
Account and request services
Backend services handle authentication, email verification, password reset, request transitions, claim transitions, and request expiry.
Behind the interface
- FlutterDonors & requesters
- Next.js APIRequests, claims & accounts
- Prisma · PostgreSQLPersistent records & states
- Request
- Staff review
- Donor response
State changes belong on the server
Request and claim services validate transitions and permissions. Transactions and request-level locks coordinate changes to the same request, rather than relying on the mobile interface alone.
A visual language for care and urgency
The published interface uses burgundy, warm white, and a blood-drop motif. Request details and urgency labels lead the experience; the case-study illustration echoes that identity without exposing donor data.
Scope & evidence
Source inspection was supplemented by an isolated local run: donor sign-in, request browsing, the request form, and authenticated staff dashboard and review screens. Screenshots use a fresh demo database; no production donor records were accessed. The public web page is an entry point to staff sign-in—not an app-store download.
These selected flows are not a complete end-to-end or clinical validation. No adoption figures, successful donations, or measured health outcomes are claimed. Matching rules are software constraints, not medical advice.
Explore the evidence
Building something with similar needs?
Tell us about your users, workflows, and integrations. We can discuss the right scope for your product.

