Recommend Richard

Know a team hiring a Product or Project Manager? Send them this message, already written for you.

Take a look at this portfolio 馃憞
Richard Cen 路 Product & Project Managerhttps://richardcen.vercel.app/en
He has led 19 developers on one OTT platform, won 30+ national awards (most as product lead) and ships products from discovery to launch.
I recommend him for Product Manager and Project Manager roles.
LinkedIn: https://www.linkedin.com/in/richard05/
Send on WhatsApp
All work

Waskita

Personal product, Apple Developer Academy2026

Parent's home: one button, nothing to configure.
Danger banner drops over the native call screen at the OTP sentence.
The child is alerted on the lock screen while the call is live.
Evidence view: the caller's sentence, highlighted, with a reason label.
From left: the parent's home screen, the Danger banner during a call, and the alert on the child's lock screen.

What it is

An iPhone app that listens to a live call, scores the risk on the device, and warns a family member.

Who it's for

Older parents who answer calls from strangers, and the adult child who wants to step in before an OTP is read out.

How it works

Speech is transcribed on the phone, a weighted risk lexicon scores it, and a sealed alert reaches the child's phone while the call is still running.

The problem

Context

Phone scams in Indonesia rarely start with a suspicious number. They start with a calm voice that slowly builds pressure until an older parent reads out an OTP. Indonesia's Anti-Scam Centre had logged 668,441 reports by August 2026.

Waskita listens to what is said in the call, on the device, and alerts a trusted family member while the call is still happening.

What we learned first

Competitors split the problem in two. Google's Scam Detection reads the conversation and has no family layer. Truecaller Family Protection has a family layer and only judges phone numbers. No one combined both, in Indonesian, on iPhone.

The dangerous moment is the handoff between phases. A warning that arrives after the call ends can only report the damage.

Constraints

  • iOS gives third-party apps no access to cellular call audio
  • Everything must stay on-device; a scam detector that uploads calls is its own privacy risk
  • Parents are not the ones who will set up an app

My role

Richard on this project

PM, designer & iOS developer (solo)

Team
1 person
Duration
Sep 2026, ongoing

Product skills

  • Competitive benchmarking
  • PRD & TRD
  • Privacy by design
  • Product states

Project skills

  • Solo delivery
  • Swift & backend
  • Automated testing
  • End-to-end device testing

As product manager

  • Benchmarked global scam-call apps before writing the PRD and TRD
  • Set the privacy model: audio is processed on the device
  • Made Danger a state that never downgrades itself

As project manager

  • Planned and built it solo, from the Swift app to the pairing backend
  • Kept 71 automated tests green across app and backend
  • Verified the whole flow end to end on two real devices

Not my role

  • No team, so every trade-off was mine to make and to explain

The work

Key decisions & trade-offs

  1. Decision 01

    Pivot when the platform said no

    Building the prototype proved what the SDK headers confirm: an app cannot record during an active cellular call. So I moved calls onto Waskita's own VoIP path (CallKit + WebRTC) and added a Practice mode as a reliable demo rail.

    Trade-off Protection only covers calls made through Waskita, and the product states that limit openly.

  2. Decision 02

    Share only the evidence

    The child sees at most three caller sentences that triggered the alert, with the phrase highlighted and a reason label. The full conversation never leaves the parent's phone.

    Trade-off Less context for the child, far more dignity and trust for the parent.

  3. Decision 03

    Put the setup burden on the protector

    The child requests a code, types it and sets the profile. The parent only shows a code and taps Allow. I also removed a four-word verification step to keep pairing to a 6-digit code.

    Trade-off Simpler pairing drops one layer of MITM protection; I documented what remains (TLS, one-time 2-minute code, peer pinning, two-sided consent).

How it was built

On-device transcription, a weighted risk lexicon (Indonesian + English), a state machine with debounce and hysteresis where Danger never downgrades itself, and a sealed alert envelope (AES-GCM) relayed to the child.

55 Swift core tests and 16 backend tests; verified across two devices: pairing, live analysis, Danger escalation at the OTP sentence, alert on the child's phone.

How it works
  1. Call answeredAnalysis starts on its own
  2. ListeningOn-device transcription
  3. CautionPressure words, claims to be a bank
  4. DangerAsks for OTP; never downgrades itself
  5. Child alertedMax 3 sentences, sealed

From the work itself

Design foundations: calm colours when safe, red reserved for Danger.
Design foundations: calm colours when safe, red reserved for Danger.
The full user flow across both phones, from pairing to post-call summary.
The full user flow across both phones, from pairing to post-call summary.

The result

2
real devices talking end to end
71
automated tests passing
32
designed screens & flows

What I'd do differently

I would test platform limits in week one, before the PRD promised anything. The pivot cost less because I found it early, but it could have cost nothing.

Indonesian on-device transcription is not available yet, so the live demo runs in English. Next: test with real parent-child pairs.

Next caseB2B heavy-equipment marketplaceA rebuild of a heavy-equipment marketplace into a procurement platform for corporate buyers.