MVP Plan

MVP Plan

1. MVP Goal

The goal of the NEPH (Neighborhood Emergency Preparedness Hub) MVP is to deliver a working first version that supports basic community coordination before and during disasters. In this version, the priority is enabling users to sign up, create and manage their profiles, submit help requests, mark themselves as available to help, and use the system’s basic assignment and coordination flow.

By the end of the MVP, the team aims to deliver a functional product that works on both mobile and web, supports the main end-to-end scenarios, and is ready for demonstration.

---

2. MVP Scope

The MVP scope is built around two main clients and one shared backend:

• Android application: the primary client focused on disaster-time use
• Web application: focused on information access, preparedness content, and administration
• Backend + database + deployment: shared data and service layer

Within this scope, only the core user flows will be completed. Advanced social features, more intelligent map capabilities, detailed analytics, extensive moderation, and expanded notification infrastructure will be left for the final milestone.

---

3. Core MVP User Scenarios

By the end of the MVP, the following core scenarios should be working:

1. A user can create an account and log in.
2. A user can view and update profile information.
3. A user in need can create a help request.
4. A volunteer can toggle their availability status.
5. The system can display open help requests and basic assignment behavior.
6. Users can view their active requests and assigned tasks.
7. On the web side, users can access preparedness content such as emergency numbers and news.

---

4. Concrete MVP Deliverables

4.1 Backend Deliverables

• User authentication system
• Profile management APIs
• Help request creation and listing APIs
• Volunteer availability status API
• Basic assignment and reassignment logic
• Foundational service structure for notifications and synchronization
• PostgreSQL-based persistent data model

4.2 Android Deliverables

• Authentication screens (sign up, login, session handling)
• Profile viewing and editing screens
• Help request creation flow
• Volunteer availability control
• Active requests / assignments screen
• Demo-ready working debug/release build

4.3 Web Deliverables

• Landing page
• Authentication pages
• Profile page
• Emergency numbers page
• News / announcements section
• Core data flows connected to the backend
• Deployed web version

4.4 DevOps / Quality Deliverables

• Well-organized monorepo structure
• Environment variable and configuration setup
• Basic CI/CD pipeline
• Basic testing and smoke-check flows
• README / SETUP instructions
• Stabilization and bug fixing before demo
• Project deployment

---

5. Feature Breakdown

5.1 Authentication

Goal: Allow users to access the system securely.

Scope:

• Sign up
• Login
• Logout
• Token/session handling

Done criteria:

• A new user can register
• A registered user can log in
• Unauthorized users cannot access protected pages

5.2 Profile Management

Goal: Allow users to define the information needed for disaster preparedness and volunteering.

Scope:

• Name and basic contact information
• Location / neighborhood information
• Volunteer skills and areas of support
• Necessary personal preparedness information

Done criteria:

• Profile data can be viewed
• Profile data can be updated
• Profile data is shown consistently across clients

5.3 Help Request Flow

Goal: Allow users in need to create help requests quickly.

Scope:

• Request category
• Urgency level
• Description
• Location information
• Request status tracking

Done criteria:

• A user can create a request
• The request is stored on the backend
• The request status is visible to the user

5.4 Volunteer Availability and Assignment

Goal: Make available volunteers visible and support basic matching.

Scope:

• “Ready to help” status
• Listing suitable volunteers
• Basic assignment logic
• Reopening tasks when needed

Done criteria:

• A volunteer can change availability status
• The system can match open requests
• Assignment information is visible on relevant user screens

5.5 Information Access on Web

Goal: Make preparedness and informational content accessible on the web.

Scope:

• Emergency numbers
• News / announcements
• Simple navigation and accessible UI

Done criteria:

• Users can access this information on the web
• Map and information pages are functional
• Content is presented clearly and in an organized way

---

6. MVP Timeline

Week	Focus	Planned Output
Week 1	Project foundation and authentication	Repo structure, environment setup, backend skeleton, authentication endpoints, Android/web authentication screens
Week 2	Profile management and help request flow	Profile APIs and UI, request creation flow, request data model, and basic request listing
Week 3	Volunteer availability and request coordination	Volunteer readiness flow, request status tracking, assignment logic foundation, and active task screens
Week 4	Web information pages and backend integration	Emergency numbers page, news/announcements section, client-backend integration, and end-to-end flow improvements
Week 5	Integration, testing, stabilization, and demo preparation	Bug fixing, deployment checks, smoke tests, documentation cleanup, and final MVP demo scenario

---

7. Task Groups

Backend

• Data model design
• Authentication implementation
• Profile endpoints
• Request endpoints
• Volunteer / assignment logic

Android

• Navigation and screen setup
• Authentication screens
• Profile screens
• Help request screen
• Volunteer / assignment screens

Web

• Landing page
• Authentication pages
• Profile page
• Emergency numbers page
• News page
• API integration and form handling

DevOps

• Environment configuration
• CI/CD setup
• Test flows
• Demo scenario validation
• Documentation updates
• Deployment and API reliability checks

---

8. Definition of MVP Completion

The MVP will be considered complete when the following conditions are met:

• The Android and web applications are deployed or in a demo-ready state
• The backend is accessible in a live environment
• The authentication, profile, help request, volunteer readiness, and basic assignment flows work end to end
• The emergency numbers, news sections on the web are functional
• The team can present a realistic end-to-end usage scenario during the demo

---

9. Known Constraints and MVP Priorities

In this MVP, the priority is not depth of features but working core scenarios. Therefore:

• Functionality will be prioritized over visual perfection
• Basic assignment logic will be implemented instead of advanced recommendation/matching systems
• Extensive moderation, offline support and advanced analytics will be left for the final milestone

With this approach, the team aims to deliver an MVP that is both technically feasible and clearly demonstrates the project idea.