VitalGrid

Real-time medical supply coordination platform for NGOs and hospitals in Africa — built on Aurora DSQL and DynamoDB to eliminate critical shortages.

Comment

Inspiration

In sub-Saharan Africa, hospitals run out of O-negative blood. Vaccines expire in one facility while another facility 40 km away has a surplus, and no one knows. Coordination happens by phone. Stock data lives in Excel files. Critical resources expire or go missing because there is no shared visibility across facilities.

We built VitalGrid to change that.

What it does

VitalGrid is a real-time medical supply coordination platform for NGOs, hospitals, and health ministries. It connects facilities across a region so that:

  • Field agents can request a transfer of critical resources in under 2 minutes
  • Facility managers approve, dispatch, and track transfers with driver information and cold-chain monitoring
  • NGO coordinators see the full regional picture, including surpluses, shortages, and transfers in transit, on a live map
  • Every movement is logged in an immutable audit trail that complies with WHO and donor reporting requirements

The platform supports 5 roles, 12 database tables, IoT temperature tracking, and automated critical alerts, all built on AWS databases.

How we built it

Frontend & API: Next.js 16.2.7 using the App Router and Turbopack, React 19, and TypeScript, deployed on Vercel.

Primary database (Aurora DSQL): All transactional data such as organizations, facilities, users, inventory, transfers, alerts, and audit logs lives in Aurora DSQL. We chose it because transfer workflows require distributed ACID transactions. When two facilities update the same blood stock at the same time, OCC conflicts are retried automatically. There are no instances to manage, it is PostgreSQL-compatible, and it scales to zero.

IoT database (DynamoDB): Cold-chain temperature events from sensors attached to transfer containers are stored here. Each reading uses transferId as the partition key and timestamp as the sort key. DynamoDB handles high-frequency sensor writes with millisecond latency. A relational database would not be suitable for this time-series workload.

Auth: JWT httpOnly cookies using jose and bcryptjs, with 5-role RBAC enforced at the Edge middleware level.

Maps: React-Leaflet with OpenStreetMap for regional facility visualization.

Challenges we faced

The hardest part was the cross-organization transfer workflow. Facilities from different NGOs such as MSF, UNICEF, and the Ministry of Health needed to exchange resources, while tenant isolation had to remain intact for security. We solved this by separating read scope, which is regional and has no tenant filter, from write scope, which is always tenant-scoped. Business rules are enforced at the API layer so that only the source facility can approve and only the destination facility can confirm receipt.

Aurora DSQL’s optimistic concurrency control model required rethinking every mutation. Every write goes through a transact() helper with automatic retries of up to five times. This was not obvious coming from traditional PostgreSQL, but it resulted in a more resilient system.

What we learned

  • Aurora DSQL is fundamentally different from RDS. The OCC model, async index creation, and DsqlSigner token rotation all require deliberate design choices.
  • DynamoDB and Aurora DSQL complement each other naturally. Relational integrity fits business data, while key-value speed fits IoT streams.
  • Building for Africa means designing for slow connections and mobile-first usage. Information density matters more than animation.

What’s next

  • Full internationalization support in French, English, Swahili, Arabic, and Portuguese
  • SMS alerts via Africa’s Talking API for facilities without reliable internet
  • Predictive stock forecasting using historical transfer data
  • FHIR-compliant data export for integration with national health information systems

Built With

Share this project:

Updates