Project Agap is a disaster risk reduction and response platform built for barangays, responders, and residents. It is designed for the moments when ordinary communication becomes unreliable but the need for accurate coordination becomes even more urgent.

At its core, Project Agap helps a community answer the questions that matter most during an emergency:

• Who is safe?
• Who still needs help?
• Which households remain unaccounted for?
• Where should people evacuate?
• What resources are needed right now?
• How can officials keep response moving even under weak connectivity?

• About
• The Platform
• Core Capabilities
  • Resident Safety Reporting
  • Barangay Command And Coordination
  • Emergency Communication
  • Evacuation Mapping And Guidance
  • Offline And Weak-Connectivity Resilience
• Development
  • Pre-Requisites
  • File Structure
  • Installation
  • Commands
  • Build
  • Deployment
• Why Project Agap Matters
• Gallery

Project Agap is not just a reporting tool. It is a coordination system built for real emergency constraints.

• it supports both residents and officials
• it bridges field action and command oversight
• it treats mapping, communication, and accountability as one integrated problem
• it remains usable during unstable network conditions
• it is tailored to barangay-level response, where timing and clarity have immediate consequences

Project Agap has two connected experiences:

• Project Agap Mobile — field app for residents, officials, and responders
• Project Agap Web Command Center — command surface for barangay leadership

Together, they form one emergency workflow across residents, responders, and decision-makers.

• one-tap I Am Safe and I Need Help status updates
• household visibility and last-ping state
• emergency reporting designed for speed and clarity

• dashboard for accountability and response KPIs
• unresolved help queue for immediate action
• household registry and evacuation status management
• welfare assignment and follow-up tracking
• center operations, occupancy, and supplies monitoring

• barangay-wide and purok-targeted broadcasts
• app and SMS-supported communication workflows
• communication history and delivery visibility

• evacuation center discovery
• safer-center route ranking
• traffic-aware route guidance when available
• seeded route fallback when live routing is unavailable
• offline map pack support for cached routes, alerts, and center data

• local-first mobile read model
• queued write recovery when live delivery is impossible
• weak-connectivity retry before queue fallback
• conflict-aware mobile recovery for official workflows
• freshness indicators so users understand what is live, stale, or pending sync

• Node.js v20+
• pnpm v9+
• Expo CLI
• EAS CLI (for APK builds)
• A Supabase project (database + auth)
• Android Studio or a physical Android device (for local runs)

project-agap/
├── apps/
│   ├── native/          # Expo React Native mobile app
│   │   ├── app/         # Expo Router file-based routes
│   │   │   ├── (auth)/      # Sign-in, sign-up
│   │   │   ├── (resident)/  # Map, status, alerts, profile
│   │   │   ├── (official)/  # Dashboard, registry, broadcast, reports
│   │   │   └── (shared)/    # Check-in, welfare-check, kiosk
│   │   ├── features/    # Feature-first modules (alerts, auth, broadcast, …)
│   │   ├── providers/   # AuthProvider, QueryProvider, OfflineQueueProvider
│   │   ├── services/    # Supabase client, notifications, offline SQLite queue
│   │   ├── stores/      # TanStack Store client state
│   │   └── shared/      # Reusable components and hooks
│   └── web/             # Next.js web command center + tRPC server
├── packages/
│   ├── api/             # tRPC router (shared between native and web)
│   ├── db/              # Drizzle ORM schema and migrations
│   ├── env/             # Zod-validated environment variables
│   └── config/          # Shared TypeScript and tooling config
├── package.json
└── pnpm-workspace.yaml

1. Clone the repository

git clone https://github.com/Polqt/project-agap.git
cd project-agap

2. Install dependencies

pnpm install

3. Set up environment variables

Create .env files in the relevant apps. For apps/native/.env:

EXPO_PUBLIC_SUPABASE_URL=your_supabase_url
EXPO_PUBLIC_SUPABASE_ANON_KEY=your_supabase_anon_key
EXPO_PUBLIC_SERVER_URL=http://localhost:3001

For apps/web/.env:

DATABASE_URL=your_database_url
SUPABASE_URL=your_supabase_url
SUPABASE_SERVICE_ROLE_KEY=your_service_role_key

4. Push the database schema

pnpm db:push

Run from the monorepo root:

pnpm install          # Install all workspace dependencies
pnpm db:push          # Push DB schema to Supabase
pnpm db:studio        # Open Drizzle Studio

Run from apps/native/:

pnpm dev              # Start Expo dev server (clears cache)
pnpm start            # Start Expo dev server
pnpm android          # Run on Android emulator or device
pnpm ios              # Run on iOS simulator

Run from apps/web/:

pnpm dev              # Start Next.js dev server
pnpm build            # Build for production
pnpm start            # Start production server

Android APK (for distribution)

The eas.json includes a judge profile for direct APK distribution:

cd apps/native
eas login
eas build --profile judge --platform android

This produces a downloadable .apk file — no Play Store required. The judge profile uses distribution: internal and buildType: apk.

Web

cd apps/web
pnpm build

Web Command Center

The web app serves as both the Next.js frontend and the tRPC API server for the mobile app. Deploy to any Node.js-compatible host (Vercel, Railway, Render, etc.).

After deploying, set EXPO_PUBLIC_SERVER_URL in your EAS build secrets to point to the deployed URL before building the APK.

Mobile

Build and distribute the APK using EAS (see Build section above). Set environment secrets in the Expo dashboard under your project's Secrets before triggering a cloud build.

Disasters do not wait for stable internet, complete information, or ideal operating conditions. Floods, earthquakes, storms, and forced evacuations create a gap between what people need to report and what systems are still capable of receiving.

Project Agap is built to close that gap.

Instead of treating connectivity loss as a failure state, the platform is designed around continuity:

• residents can still report safety status quickly
• officials can continue operations from mobile in the field
• command staff can maintain barangay-wide visibility from the web
• map, routing, alerts, and cached records remain useful even when live services degrade
• weak connections are treated as recoverable, not immediately lost

Screenshots and demo recordings of the platform in action.

• Mobile field app: apps/native/README.md
• Web command center: apps/web/README.md