PRD Agent logoPRDAgent

Don't Click That — scam/fraud blocker for seniors across email, SMS texts, and phone calls (start with Gmail + Android) plus a family dashboard.

COMPLETE
TBD
$30,000
3 features
3 milestones
1 role

Project Overview

Problem Statement
Modern scams are highly convincing across email, text, and voice; elders are increasingly defrauded and existing filters miss elder-specific threats. Need proactive screening/blocking before messages/calls reach the person, with visibility for adult children.
Ideal Customer Profile
Families with elderly parents at risk of scams/fraud; adult children/caregivers who want protection + visibility. Secondary: financial advisors recommending protection to clients.
App Audience
Public-facing consumer app with family-admin dashboard; plus partner/referral distribution via advisors.
Project Type
Greenfield (new build)
Integrations
MVP: Gmail + Android (email access, SMS permissions, call screening). No additional integrations for MVP.
Tech Stack Preferences
Open to engineer suggestions. Preference for cross-platform approach if (and only if) it can support required capabilities (Gmail access, Android SMS/call screening, family dashboard).
Deployment Preferences
Keep it simple and cheap; open to pragmatic hosting choices.
Design Status
No existing designs; engineer-led MVP design is fine.

Features

Android call screening (scam/spam calls)
Screen incoming calls on Android using call screening APIs and reputation signals; warn, silence, or block suspected scam/spam calls before the user answers. Provide basic rationale for the decision and allow user overrides/whitelisting.
  • Implement Android Call Screening integration

    Use Android CallScreeningService / relevant APIs; request permissions; handle call details and screening response actions (allow, disallow, silence, reject).

  • Call reputation / detection logic (MVP)

    Start with heuristics and/or a call reputation dataset (TBD); support configurable sensitivity and basic categories (scam likely, spam, unknown).

  • User controls: allowlist/blocklist & feedback

    Allow user to mark numbers as safe/unsafe; capture feedback to improve detection.

  • Logging & audit trail (local or minimal backend)

    Store screened call events with timestamp, number, result, and reason to support transparency and later dashboarding.

Android SMS scanning (scam texts)
Monitor incoming SMS on Android and flag/block suspected scam texts (delivery scams, bank alerts, utility shutoff threats, etc.). Provide explanations and allow user overrides; tune sensitivity to minimize false positives so users keep it enabled.
  • SMS permissions & ingestion

    Implement required Android permissions and ingestion approach for SMS (noting platform restrictions); capture message metadata/content needed for detection.

  • SMS detection logic (MVP)

    Heuristics + pattern matching for common scam categories; optionally integrate a phishing/fraud detection API if available.

  • User controls: allowlist/blocklist & feedback

    Let users mark sender/number as safe/unsafe and submit feedback on false positives/negatives.

  • Local storage of flagged texts + rationale

    Store flagged SMS events (timestamp, sender, action, category, rationale) to support transparency and later dashboarding.

Family dashboard (MVP)
Provide a family view showing what scam calls/texts were blocked and why, without requiring full access to the senior’s device. Focus on transparency and peace of mind; support basic family linking/invite flow.
  • Define MVP dashboard surface (web vs in-app)

    Decide if dashboard is a simple web app or a section within the mobile app; confirm required functionality and permissions.

  • Family linking / invites

    Implement invite flow (e.g., senior invites adult child via link/code) and basic roles (senior vs family viewer).

  • Event feed for blocked calls/texts

    Display a feed of blocked events with timestamp, category, and rationale; allow filtering by calls vs texts.

  • Minimal backend/storage for sync

    Implement minimal storage/sync so family can view events remotely (e.g., Firebase/Firestore); ensure privacy and least-privilege data sharing.

Milestones

Milestone 1

Milestone 1 — Android call screening MVP
Implement Android call screening with default auto-blocking, basic detection logic, user controls, and event logging needed for transparency and later dashboarding.
$12,000

Assigned Features

  • Android call screening (scam/spam calls)

Milestone 2

Milestone 2 — Android SMS scanning MVP
Implement Android SMS scam detection with default auto-blocking, categories/rationale, user controls/feedback, and event logging to support transparency and the family dashboard feed.
$10,000

Assigned Features

  • Android SMS scanning (scam texts)

Milestone 3

Milestone 3 — Family dashboard + MVP release polish
Deliver the family dashboard MVP (linking/invites, event feed) backed by minimal sync storage, plus end-to-end QA, tuning to reduce false positives, and pilot readiness for early families.
$8,000

Assigned Features

  • Family dashboard (MVP)

Skills Needed

Mobile Engineer (Full-stack-capable)
Single engineer can deliver the MVP end-to-end: Android-first mobile app (optionally cross-platform UI) plus minimal backend/dashboard and lightweight deployment.
AndroidKotlinReact Native or FlutterAPI integrationFirebase or simple backend services

Open Questions

What is the target timeline for the MVP launch and subsequent rollout (e.g., SMS monitoring by ~6 months)?
Founder is unsure of timeline; needs discussion to align scope, validation plan (e.g., 20-family pilot), and engineering effort for Gmail/Android call screening + dashboard.
Can a cross-platform mobile approach (e.g., React Native/Flutter) support the required Android-specific capabilities (SMS filtering, call screening, Gmail integration) without compromising core functionality?
Founder prefers cross-platform for speed/coverage but only if it supports all required permissions/APIs. Needs engineering validation and possibly a hybrid (cross-platform UI + native Android services) approach.
For MVP, should the product include a family dashboard, or is this explicitly out of scope? If included, where should it live (in-app, web) and what minimum data should it show?
Include family dashboard in MVP. Dashboard location: web dashboard. Minimum dataset/UX and auth/invite flow: engineer to decide.