Pinboard archive / Engineering case study
Context
The donor-facing half of the university Blood Bank platform, designed to connect appointments and donation history with staff operations.
- Working context
- I built this with my university team as part of the wider Blood Bank platform.
- My role
- I implemented most of the wider platform as part of the team; responsibility was shared across modules.
- Who was affected
- Blood donors using a mobile device and staff processing their appointments.
Problem brief
Problem
Donors need mobile access to registration, appointments, history, and updates that remains connected to staff operations.
Operating constraints
- 01Mobile, API, desktop, and SQL Server state must describe the same appointment workflow.
- 02Authentication and donor medical details cross a network boundary.
Evidence / reasoning
Problem Research
End-to-end appointment state
I traced a booking from the donor's phone to staff-visible work, donation processing, history, and the final donor update.
Mobile service boundary
I separated screen state, Provider responsibilities, REST services, and persistence concerns before mapping the mobile flows.
Implementation files
How I Solved It
Donor account
I connected registration, login, profile, blood details, and donation history in the donor account experience.
Appointment workflow
I built a scheduling flow for selecting a date, time, and location and receiving a confirmation state.
Notifications
I included appointment, request, and system notification states in the interface.
System map
System Architecture
Diagnostic notes
Challenges
Cross-application consistency
A donor action must become coherent work in a separate desktop application.
Network authentication state
Login, profile, and protected donor data must remain coherent when requests fail or sessions expire.
Growing mobile state
Accounts, appointments, history, and notifications can couple screens directly to transport code.
Quality gates
Technical Safeguards
API security
I used JWT authentication, CORS policy, Swagger contracts, and structured error handling at the API boundary.
Maintainability
I assigned explicit Flutter responsibilities to models, providers, routes, screens, services, utilities, and widgets.
Ownership record
My Contribution
I implemented most of the wider team platform while sharing responsibility across the mobile, API, desktop, and database modules.
- Working context
- I built this with my university team as part of the wider Blood Bank platform.
- My role
- I implemented most of the wider platform as part of the team; responsibility was shared across modules.
Closing record
Outcome
Our platform includes a donor-facing Flutter application, ASP.NET Core API, shared database, and an appointment-to-donation workflow connected to staff operations.
Our project includes the Flutter application, ASP.NET Core API, shared database setup, Swagger access, and end-to-end appointment workflow.
I present the mobile, API, and desktop integration as shared team work; automated cross-client appointment tests are the next technical step.
My next technical step is to add automated API and client-state tests for authentication expiry and appointment transitions across both clients.
Curated project media
Related Evidence
