Context
HiRobin is an AI call-screening Android app with 1.1M installs and approximately 296K monthly active users in the September 2026 snapshot. I was the lead mobile contributor, building call-handling surfaces and the native and service integrations around them. Installs describe distribution; monthly active users describe usage. Neither is a revenue outcome.
The difficult part
A screen is only one part of a calling workflow. Android permissions and telephony behavior, call-forwarding configuration, payment outcomes, and live server events each have independent states. The interface needs to communicate what is ready, what is pending, and what requires action. Voice-over-IP (VoIP) work remains foundational rather than a claim of a completed platform.
My responsibility
I built the co-pilot overlay, calls inbox, call-detail sheet, USSD call-forwarding setup, and in-app transcripts. I implemented native cold-start prefetch that seeds the React Query cache, notification deep-link routing, and new-architecture native modules. I owned a release train spanning 15+ production versions, including accessibility-service consent and an update gate. Payments and subscription work crossed the React Native client and Python backend: UPI mandates, trial/grace/premium states, and payment recovery. These are personal contributions within a team, not sole ownership of the entire product.
Product usage: September 2026 snapshot. Contribution period: January–September 2026. Installs and active users are distinct measures; product scale is team context.
Call handling
Co-pilot overlay, calls inbox, call-detail sheet, in-app transcripts, and USSD call-forwarding setup. The core call-handling surfaces reached approximately 113K–125K monthly users in the supplied snapshot.
Startup & client state
Native cold-start prefetch seeding the React Query cache, notification deep-link routing, PowerSync offline cache, and a server-driven home timeline. The native hydration path served approximately 96K monthly users.
Platform & release ownership
New-architecture native modules, VoIP microphone and overlay fixes, and 15+ production versions from 1.4.9 to 1.8.8. Release work included screen-scan consent, accessibility-service compliance, and a health-driven forced-update gate.
Payments & subscriptions
End-to-end React Native and Python backend work: Razorpay UPI mandates, trial/grace/premium states, and payment-recovery workflows.
System model
Permissions & lifecycle
Payments & calling
Decisions & tradeoffs
Cross the native boundary when the feature requires it
Telephony and dialer behavior depend on Android capabilities below the React Native interface. Native modules make those platform capabilities available to the product.
Native integration adds device, permission, and lifecycle behavior to the verification surface.
Seed the client cache from native startup work
Native cold-start prefetch brings data into the React Query cache before the JavaScript interface would otherwise retrieve it. The hydration path served approximately 96K monthly users in the supplied snapshot.
Native and JavaScript cache state need a consistent handoff. No measured before/after latency claim is made here.
Model subscriptions across the client and backend
Trial, grace, premium, and payment-recovery states need one understandable user journey even when a payment is delayed or interrupted.
A wider integration boundary requires careful coordination and a clear account of which system confirms each outcome. Shipping this infrastructure does not establish revenue or conversion impact.
Failure modes considered
Constraints to discuss in an interview; implementation-specific recovery details remain private.
Platform permission or lifecycle restrictions
A native capability is not equivalent to a ready feature. Permission and platform state must be considered together.
Connection loss during live communication
Disconnected transport and an ended conversation are different states. Recovery behavior is an important interview topic.
An uncertain payment outcome
A dismissed or interrupted payment interaction cannot by itself establish subscription status.
Outcome
Lead mobile contribution to a product with 1.1M installs and approximately 296K monthly active users. September 2026 snapshot.
What I would examine next
The useful next question is how much of each workflow can be exercised independently of a physical call or a live payment. Explicit client/native/service boundaries make that discussion possible without exposing proprietary implementation details.
Ask me about this work.
- When did a native Android module become necessary?
- How do you distinguish platform readiness from UI readiness?
- How do payment and live-event states reach the client?