Overview
How should mobile roles, health-related reminders, location, and shared safety data stay understandable and consistent across app and backend boundaries?
Caregiving is a shared workflow. The product must support different capabilities for elders and caregivers while keeping critical information easy to reach.
Problem
The system joins role-specific Android experiences with backend state, reminders, contacts, and location data where stale or ambiguous information reduces trust.
Constraints
- Different caregiver and elder permissions
- Sensitive health, contact, and location context
- Reminder reliability across device states
- Clear recovery from API or connectivity failures
- Consistent data across multiple users
Architecture
Two roles, shared care context
Select a role or boundary to explore how care information crosses the app, API, and data layers.
Compose workflows make reminders, trusted contacts, and safety information accessible to elders.
Caregivers coordinate care using a different set of product capabilities and shared information.
Node.js and Express connect mobile workflows to shared data. Role authorization remains an implementation boundary to verify.
Shared care data belongs behind the API boundary; devices do not access the database directly.
Reminders, contacts, and location require clear ownership, consent, freshness, and failure states.
Trace a relationship
Focus or hover a node to highlight its connections. Select to keep it highlighted; select again or press Escape to clear.
Conceptual architecture from the project brief. Arrows show information direction, not live traffic.
Read all responsibilities and connections
- Elder app
- Compose workflows make reminders, trusted contacts, and safety information accessible to elders.
- Caregiver app
- Caregivers coordinate care using a different set of product capabilities and shared information.
- REST API
- Node.js and Express connect mobile workflows to shared data. Role authorization remains an implementation boundary to verify.
- MongoDB
- Shared care data belongs behind the API boundary; devices do not access the database directly.
- Care context
- Reminders, contacts, and location require clear ownership, consent, freshness, and failure states.
- Elder app → REST API: role-specific requests
- REST API → Elder app: care information
- Caregiver app → REST API: coordination requests
- REST API → Caregiver app: shared care information
- REST API → MongoDB: read and persist
- MongoDB → REST API: stored records
- Care context → REST API: product operations
Engineering decisions
Design rationale from the project brief. Code-level examples and measured tradeoffs are pending verification.
Decision 01
Model roles as product capabilities
Caregiver and elder differences belong in domain rules, not scattered UI conditions.
Decision 02
Make sync state visible
Users need to distinguish confirmed information from pending or unavailable network state.
Decision 03
Keep safety paths short
Contacts, reminders, and location actions must remain legible under stress and on small screens.
Tradeoffs to validate
Comparison of the design directions in this brief, pending confirmation against the implementation.
- Design direction
- Express roles at the API boundary
- Alternative
- Hide controls in the mobile UI alone
- Consequence
- Backend authorization and mobile capabilities must stay aligned. A simpler UI-only distinction cannot enforce data access.
- Design direction
- Expose pending or stale information
- Alternative
- Always display the last value as current
- Consequence
- More interface states require careful explanation, but avoid giving caregivers false confidence in old information.
Implementation
Implementation scope based on the supplied project description.
Build role-specific mobile workflows
Android and Jetpack Compose support caregiver and elder experiences spanning reminders, contacts, safety, and location.
Connect app and shared data
REST endpoints connect the mobile application to Node.js, Express, and MongoDB. Role permissions and data ownership are central contract decisions.
Handle incomplete information
Reminder delivery, location freshness, and API failures are reliability concerns. The exact recovery mechanisms need code or product-flow evidence before they can be documented as implemented behavior.
Challenges and reliability
Reliability concerns that shape the engineering work:
- Role-aware authorization and API contracts
- Explicit loading, stale-data, empty, and failure states
- Reminder and location behavior designed around mobile lifecycle constraints
Outcome
Jaga Ortu shows product engineering across the mobile-backend boundary, with architecture shaped by trust, role clarity, and operational reliability.
Evidence to add
This case study describes engineering scope. Quantified outcomes and implementation claims need supporting material.
- Verified role and permission matrix
- API contract and reminder lifecycle examples
- Screenshots of connectivity, consent, and recovery states
Technology
- Kotlin
- Primary Android language
- Android
- Lifecycle, services, platform APIs, and product delivery
- Jetpack Compose
- Declarative Android UI
- MVVM
- Predictable presentation state and responsibilities
- Clean Architecture
- Domain boundaries and testable change
- REST API
- Mobile-backend contracts and failure handling
- Node.js
- Application backend runtime
- Express
- REST API surface
- MongoDB
- Shared caregiver and elder data
- Location
- Consent-aware safety context