Review 6 of 6 — Skeptical Product / Scope Critic

Reviewer lens: is this worth building, for one technical owner, on his own Samsung (maybe Pixel), and what is the smallest thing that proves it?

Inputs: PRD-original.md (truncated at §7) and DESIGN-DRAFT.md. Date: 2026-10-03.

Bottom line. The PRD is written like a consumer product heading for the Play Store. It carries Play-policy constraints, consumer-grade transparency settings and five numeric dimensions. The owner is one person sideloading onto his own phone. Most of the scope protects against problems he does not have.

The draft's claimed differentiator is the stateful trajectory (opener → wrong-number pivot → platform shift → investment). As of 2026 that is exactly what Google's on-device Scam Detection targets, and it is on by default for non-contacts. The genuinely unique value is narrower:

1. Personal expected-sender context.
2. Explanation of why.
3. Calmer handling of low-context unknowns.
4. A one-tap "who is this?" draft.

That is a 2-week build, not a multi-phase program. Gate it on a measured volume of unknown-sender messages before writing the classifier.

---

1. Is notification-only data enough?

For the narrow core value ("don't call a stranger spam just because they're a stranger"), mostly yes. For the PRD's full ambition (history-aware, multi-signal trust), no.

The estimates below are reviewer judgment, not measurements. The Phase 0 probe should replace them with real numbers.

Net: notification-only keeps maybe 50–65% of the conceivable value. Almost all the loss is on the legitimacy side (history), not the risk side. That is backwards for this product, which exists to protect legitimacy.

Cheap recovery the PRD forbids by inheritance, not necessity. READ_SMS and READ_CALL_LOG are banned by Google Play policy, not by the OS. For an adb-installed personal app they may be grantable. Mark this verify in the spike, because hard-restricted permission allowlisting and Android 13+/15 "restricted settings" may still gate it. Two caveats:

• RCS messages are not in the SMS content provider (Google Messages keeps them in its own store), so READ_SMS yields SMS/MMS outbound history only.
• READ_CALL_LOG ("I called or was called by this number") is a strong, cheap legitimacy signal and covers the RCS gap partially.

This contradicts PRD §4.2. It is labeled as an owner decision: "the non-goal exists because of Play policy, which does not apply to a personal sideload; revisit?"

Cheap partial fix for spam-folder blindness (on-thesis, high value): if an expected sender (dentist, FedEx, new employer) is due and no matching message has arrived by the expected time, nudge: "Expected Bright Smile Dental — nothing arrived. Check Spam & blocked in Messages." That is the only way a notification-only sidecar can rescue a stranger Google filed away.

---

2. Competitive reality (2025–2026)

What this means for the draft's "differentiator":

• Stateful trajectory is not unique. It is Google's headline feature, on by default, aimed at exactly the same non-contact population. If Byron's phone is an S26 or Pixel 10, Gemini Nano already does it. On an older Samsung he gets the non-Gemini version.
• Question for Byron: which exact device model and Messages version? The answer moves the trajectory feature between "redundant" and "modest value".
• Bulk spam, link phishing and toll/package scams are already heavily filtered upstream (carrier, then Google). By the time a notification fires, the easy scams are mostly gone. The sidecar's risk ledger will mostly re-confirm Google.

Residual problem only this app solves:

1. Personal context. "I'm expecting Carlos from The Ashford and a FedEx this week." No platform filter knows that, and it is what moves a legitimate stranger from unknown to likely legitimate. This is the product.
2. Explanation. Google says "likely scam". The sidecar says which evidence and what it doesn't know. That matters most when Google is silent: "Unrecognized: no self-ID, no link, no ask."
3. Tiered attention for unknowns. Google has two states, inbox or spam. Nothing gives a middle "real but low-context, look later" tier.
4. "Who is this?" in one tap. It is small, but it is the most-used action.
5. The expected-sender-missing nudge, as the only window into the spam folder.

Everything else in the PRD duplicates work done upstream.

---

3. Scope: v1 is over-scoped. The 2-week version:

Ranked by value ÷ effort:

Total kept ≈ 10–11 working days. That fits 2 weeks with slack for Samsung battery-optimization fights.

---

4. Would becoming the default SMS app, or using Samsung APIs, change the calculus?

• Default SMS app: no. It is a non-starter while contacts use RCS. Only Google Messages (and Samsung Messages, by special arrangement) can use RCS. Third-party default apps fall back to SMS/MMS. https://www.xda-developers.com/google-messages-rcs-api-third-party-apps/ Becoming default would also forfeit Google's own Scam Detection and spam filter, the very layers the sidecar complements. It would buy full history plus spam-folder visibility at the cost of RCS and Google's protection. That is a bad trade.
• Samsung-specific APIs: none public for Messages content. Samsung is converging on Google Messages in the US anyway.
• What actually changes the calculus (rejected by default under the PRD): the web-pairing route, i.e. a Google Messages "Device pairing" client such as the open-source mautrix-gmessages bridge. It gives full threads, outbound history, media, and SMS + RCS. https://docs.hacklab.fi/matrix/gmessages.html It breaks three explicit PRD rules: an unofficial/private protocol, off-device processing (though it could run on Byron's own Mac Mini), and a full mirror. It is listed only so the owner can make an informed choice. It is not recommended for v1, and it can break whenever Google changes the protocol.
• Smaller real upgrade: READ_SMS + READ_CALL_LOG on a sideloaded build (§1). It recovers most of the outbound-history value without abandoning Google Messages. Verify grantability in the spike.

---

5. Biggest risks the project fails, most likely first

1. Low volume makes it pointless (most likely). Carrier and Google filters remove most junk upstream. If Byron gets ~2–5 non-spam unknown-sender texts a week, the sidecar annotates a handful of notifications, the verdict is usually "Unrecognized", and he stops looking within a month. Mitigation: the probe measures volume for 14 days before any classifier work. Proceed only if non-contact, non-short-code inbound is ≥5/week (owner can tune the threshold).
2. Redundancy with Google. On an S26 or Pixel 10, Google's Gemini detection covers the risk side. If the sidecar never catches something Google missed, the risk ledger is dead weight. Mitigation: the metric "catches Google missed" (§6). After 60 days at zero, shrink the risk side to tripwires only.
3. Notification-access erosion. Android 15 already redacts OTP-class notifications from untrusted listeners. If Google widens the "sensitive" class (financial or account alerts), analysis completeness drops. Google Messages could also change its MessagingStyle payload in any update. Mitigation: the probe's structure log doubles as a regression alarm. Re-run it after each Messages update.
4. Samsung process-killing. Aggressive battery management unbinds listeners, and the sidecar silently stops. This is annoying in annotate mode and dangerous in quiet mode, which is why quiet mode is cut. Mitigation: heartbeat plus a "sidecar not running" alert.
5. Sideloading policy. Android developer verification is global in 2027+. adb installs and the "advanced flow" remain exempt, and a hobbyist limited-distribution account covers up to 20 devices. Low risk for this owner. https://android-developers.googleblog.com/2026/03/android-developer-verification-rolling-out-to-all-developers.html
6. Google ships the unique part. "Why flagged" explanations or an unknown-senders middle tier inside Google Messages would erase differentiators 2 and 3. The personal-context ledger is the most defensible piece.

---

6. Success metrics for a personal tool

Keep it to six numbers, read from the local log, reviewed at day 30 (go/no-go) and day 60:

1. Volume gate: non-contact, non-short-code inbound per week. Below 5/week, stop or shelve.
2. Zero harmful false alarms: count of legitimate messages labeled Likely scam. Target 0 over 30 days, and any instance is a rules bug.
3. Legitimate-stranger lift: of the strangers Byron later marks legitimate, the % the sidecar had already rated Likely legitimate (via context ledger, short code or brand). Target ≥50%. This is the "unknown is not malicious" metric.
4. Catches Google missed: messages rated Suspicious or worse where Google Messages showed no warning. If it is 0 after 60 days, cut the risk ledger to tripwires.
5. Spam-folder rescues: expected-sender nudges that led to finding a real message in Spam & blocked. Any nonzero count justifies the feature.
6. Uptime: % of Google Messages notifications the sidecar processed, from the heartbeat versus the probe count. Target ≥98%.

A soft signal: does Byron open the annotation at least weekly by week 4? If not, the tool has become furniture. Kill it, or fold the expected-sender idea into something he already looks at.

← Back to the proposal