Give active Android users a faster in-composer drafting path after the mobile web workflow proves that app switching is the real friction.
Product requirements
Android ReplyPilot Keyboard requirements
Android ReplyPilot Keyboard requirements should begin only after mobile web share/copy proves repeat demand. The Android keyboard should reduce native composer friction by inserting selected drafts, using the same TypeToSell account and quota, explaining keyboard privacy plainly, avoiding hidden social account access, and leaving final posting manual.
Last updated: July 11, 2026. This page is written for PRD-intent SEO and AI citation.
Product goal
What should this requirement set accomplish?
Functional requirements
What must the product do?
Keyboard drafting surface
The keyboard exposes a compact way to request or retrieve reply drafts near the native composer.
Selected draft insertion
Only a user-selected draft is inserted into the active text field.
Shared account entitlement
The keyboard uses the same TypeToSell login, subscription, quota, and revoke logic as the web app.
Mobile web fallback
Users can return to mobile web share/copy when keyboard context, permissions, or beta access are limited.
Acceptance criteria
What must be true before this is ready?
Criterion 1
Demand is proven first
Android keyboard build starts after mobile web users repeatedly generate, copy, and request native speed.
Criterion 2
Insert is not publish
Users can distinguish inserting selected text from posting a social reply.
Criterion 3
Privacy copy is visible
The keyboard explains what it does, what it does not read, and why permission is needed.
Criterion 4
Roadmap honesty is preserved
Pages do not imply current Google Play availability unless a shipped listing is visible and verified.
Non-functional requirements
What quality bars must hold?
Permission trust
Keyboard permission language should be plain, specific, and not evasive.
Sensitive text minimization
Avoid storing raw posts, private messages, generated replies, or billing data in keyboard-local storage.
Abuse resistance
Rate limits, quota, and account revoke flows must work before a public keyboard rollout.
Manual posting consistency
The Android surface must keep the same draft, choose, edit, and manual final click model.
Out of scope
What should not be built or claimed?
Keyboard auto-posting
The Android keyboard should never press final social platform actions.
Broad keyboard logging
The keyboard should not be positioned as reading everything the user types.
Native build before proof
Android work should not start from preference alone without mobile web evidence.
Related reading
Continue from requirements to execution
Android keyboard prebuild checklist/checklists/android-replypilot-keyboard-prebuild-checklistAndroid keyboard validation roadmap/roadmaps/android-replypilot-keyboard-validation-roadmapAndroid keyboard workflow/workflows/android-replypilot-keyboard-workflowAndroid keyboard vs mobile web decision/decisions/android-keyboard-vs-mobile-web
FAQ
Requirement questions
When should Android ReplyPilot Keyboard requirements be used?
Use them after mobile web validation shows Android users want in-composer speed.
Does Android ReplyPilot Keyboard post automatically?
No. It should insert selected text only, then the user edits and manually posts.
Is Android ReplyPilot Keyboard currently live?
These requirements describe roadmap planning and should not be treated as current Google Play availability.