phoenix
phoenixPhoenix - Your AI Assistant
Inactive session will be ended in 24 hours
End Session

Vanguard Guardian

  • Posted:
  • Proposals: 15
  • Remote
  • #4496970
  • Open for Proposals
Williams O.Zain U.Amaneet B.Bombay SoftwaresMuazam A. + 10 others have already sent a proposal.
  • 3

Description

Experience Level: Expert
PROJECT BRIEF — UK MOBILE APP DEVELOPER (FLUTTER / REACT NATIVE)

Project: Vanguard Guardian

I am seeking an experienced UK-based mobile developer (freelancer or boutique team) to build a production-ready MVP for Vanguard Guardian, a discreet safeguarding / lone worker safety platform.

This is a safety-critical product, not a generic consumer app. Reliability, privacy, escalation logic, background behaviour, and realistic technical constraints matter.

PRODUCT OVERVIEW

Vanguard Guardian enables users to start active safeguarding sessions with trusted contacts pre-configured.

If a user:
- manually triggers an alert
- misses a welfare check
- unexpectedly ends/disconnects a session

…the system escalates with actionable incident information.

Core philosophy:
PROTECT → DOCUMENT → RESPOND → REFLECT

MVP SCOPE

AUTH
- signup
- login
- persistent auth
- password reset

TRUSTED CONTACTS
- add/edit/remove contacts
- phone + email
- escalation ordering

SAFEGUARDING SESSIONS
- start session
- extend session
- safe exit
- timed welfare check-ins
- missed check escalation
- unexpected session end escalation
- manual emergency trigger

INCIDENT RESPONSE
- incident creation
- trigger reason logging
(manual / missed welfare / unexpected end)
- timestamps
- last known GPS
- responder incident page

LOCATION
- active GPS
- background location handling
- map integration
- location persistence

EVIDENCE
- emergency audio recording
- short instant evidence clip
- secure storage
- downloadable evidence

DISCREET MODE
- neutral icon mode
- muted notifications
- concealed controls
- privacy-focused UX

AFTER ACTION REPORTING (MVP REQUIREMENT)
A core differentiator, not optional:
- structured post-incident reflection
- incident notes
- extra evidence upload
- export/share summary
- reflective prompts

SUBSCRIPTIONS
- Apple App Store subscriptions
- Google Play subscriptions
- tiered plans

ROADMAP (NOT MVP BUILD SCOPE)

Future phases only:
Phase 2:
- route tracking
- ETA monitoring
- route deviation alerts
- inactivity detection
- discreet cover call workflows

Phase 3:
- AI distress phrase detection
- silence anomaly detection
- behavioural escalation intelligence
- trusted emergency audio listen-in

Enterprise:
- institutional dashboards
- compliance reporting
- safeguarding workflows

CRITICAL TECHNICAL REQUIREMENT

A potential major differentiator is discreet safe phrase / wake-word emergency triggering.

Because Apple constraints may apply, I need complete candour.

Milestone 1 MUST determine technical feasibility.

Please explicitly state whether safe phrase detection can reliably function in:
- foreground
- background
- screen locked
- low power mode
- after interruptions
- after suspension
- after force-close

Please clearly identify:
- what is reliably achievable
- what is best effort only
- what is impossible / non-compliant

MILESTONE 1 REQUIREMENT

Milestone 1 is not generic development.

Its explicit purpose:

TECHNICAL FEASIBILITY VALIDATION

Including:
- iOS background execution validation
- wake-word feasibility validation
- architecture validation
- practical behaviour demonstration

Commercially:
If safe phrase triggering is represented as in scope, feasibility must be proven in Milestone 1 acceptance.

This technical risk should not sit solely with the client.

Milestone 1 payment is contingent on agreed acceptance criteria.

TECH STACK

Open to:
- Flutter
OR
- React Native

Backend:
Open to recommendation:
- Firebase
- Supabase
- API-first architecture
- Xano hybrid

DELIVERABLES
- iOS MVP
- Android MVP
- TestFlight builds
- Play internal builds
- documentation
- client-owned repos
- client-owned credentials
- source code ownership

COMMERCIAL REQUIREMENTS
- UK-based only
- milestone delivery
- explicit acceptance criteria
- escrow / protected payments
- no large upfront transfers
- weekly progress visibility

PLEASE INCLUDE
1. shipped iOS apps
2. shipped Android apps
3. background GPS experience
4. audio handling experience
5. wake-word / speech detection experience
6. App Store deployment experience
7. preferred stack
8. estimated timeline
9. estimated budget
10. freelance or studio

I already have a working Vanguard prototype and product materials that can be shared to reduce scope ambiguity.

New Proposal

Login to your account and send a proposal now to get this project.

Log in

Clarification Board Ask a Question

  • VCONN P.

    Hi Joshua,

    Thanks for the invite:

    Before confirming architecture, timeline, and commercial structure, I’d like to clarify a few Vanguard-specific points so I can accurately assess feasibility and technical risk:

    1. Is responder escalation SMS-based, push-based, email-based, or multi-channel?

    2. Are you expecting live responder tracking or snapshot incident views only for MVP?

    3. Will emergency evidence uploads require end-to-end encryption?

    4. Is safeguarding data subject to any institutional/compliance framework?

    5. Do you already have UX flows/wireframes from the existing prototype?

    6. Are you expecting smartwatch integration in future phases?

    7. Do you want discreet mode to alter app branding dynamically or simply conceal notifications/UI?

    8. What level of offline survivability is required?

    9. Are emergency calls/SMS auto-triggered or user-confirmed?

    10. Is there a web responder dashboard in MVP scope or mobile-only?

    Looking forward to your answers.

    Best Regards.

    Joshua W.Yesterday

    Hi,

    Thanks — these are sensible questions.

    At this stage I’m still refining delivery partner selection and MVP architecture, so some of this is intentionally directionally defined rather than fully locked, but current thinking is:

    1. Responder escalation

    MVP should be multi-channel.

    Primary:
    - SMS
    - email

    Potential future:
    - push notifications for registered responders

    The core requirement is resilient escalation, not dependence on a single channel.

    2. Live tracking vs snapshot

    MVP expectation is incident-centric response rather than continuous live tracking.

    Meaning:
    - last known location
    - incident trigger context
    - timestamps
    - evidence access
    - response workflow

    Live tracking / richer responder monitoring can sit in future roadmap phases.

    3. Evidence encryption

    Secure storage is required.

    Formal end-to-end encryption is not currently defined as an MVP hard requirement, but security/privacy architecture matters and should be designed appropriately.

    4. Compliance

    Initial MVP is consumer / safeguarding focused rather than institutionally regulated.

    Future roadmap may include organisational / safeguarding provider workflows where stronger compliance requirements would become relevant.

    5. Existing prototype

    Yes.

    A working prototype exists along with product thinking, UX concepts, and workflow logic.

    That would be shared only under NDA / confidentiality agreement once commercial fit is established.

    6. Smartwatch integration

    Not MVP.

    But yes, potentially relevant future roadmap depending on product evolution.

    7. Discreet mode

    For MVP:

    - concealed / neutral UI
    - discreet operational behaviour
    - notification/privacy handling

    Dynamic app rebranding is not current MVP scope.

    8. Offline survivability

    Reasonable graceful degradation is important.

    Core emergency workflows obviously depend on connectivity, but the product should behave intelligently under poor signal conditions rather than simply fail unpredictably.

    9. Emergency triggering

    Depends on trigger type.

    Examples:

    Manual emergency:
    immediate.

    Wake phrase:
    immediate.

    Unexpected armed-session interruption:
    likely grace logic / configurable safeguarding escalation to reduce false positives.

    10. Responder interface

    Yes, MVP includes responder-facing incident response capability.

    Current expectation is lightweight secure web responder experience rather than requiring responders to install a dedicated mobile app.

    At this stage the most important architectural question remains the discreet safeguarding session model, wake phrase interaction model, and overall mobile lifecycle reliability.

    That’s the core differentiator being carefully pressure-tested.

    Best,
    Josh

    VCONN P.Yesterday

    Thanks for the detailed clarification.

    Based on your answers, my current technical view is:

    • the safeguarding session architecture is achievable
    • background GPS + escalation workflows are achievable
    • lightweight responder web experience is sensible for MVP
    • discreet UX behaviour is feasible
    • wake phrase reliability remains the primary technical risk area, particularly on iOS

    I’d be happy to review the existing prototype/workflows under NDA before moving into formal scoping.

    One additional question from my side before I’d be comfortable committing to milestone structure and delivery scheduling:

    -What is your target launch timeline for the MVP?
    -And what budget range are you currently expecting to allocate for:

    -the feasibility milestone
    -and the full production MVP?

    I ask because safeguarding-critical apps sit in a very different complexity category than standard consumer apps — particularly once background lifecycle handling, escalation reliability, audio capture, subscriptions, and App Store compliance are involved.

    Looking forward.