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
Hayah staff dashboard showing demo request counts, donor blood-type charts, and request states.
Hayah donor screen with blood type, availability, urgency filters, and two fictional blood requests.

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.

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

  1. Create a request

    A requester supplies the blood type, governorate, urgency, and needed-by date. New requests enter a review state.

  2. Review and publish

    Authorized staff can approve or reject pending requests. The backend checks the request’s current state before allowing a transition.

  3. 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
Hayah
  1. Request
  2. Staff review
  3. Donor response
Workflow illustration — not an application screenshot.

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.

Discuss your project
Next case studySellevaMobile commerce & administrationAll case studies