Roadmap

Android ReplyPilot Keyboard validation roadmap

The Android ReplyPilot Keyboard validation roadmap should begin only after mobile web share/copy shows repeat demand. The goal is to test whether an Android keyboard reduces app-switching friction inside the X app and other social composers while preserving selected-draft insertion, editing, and manual final posting.

Last updated: July 11, 2026. Roadmap pages do not claim native app-store availability unless explicitly proven.

Strategic fit

When this roadmap matters

Use this roadmap when mobile users want faster native reply composition but TypeToSell still needs to keep social account safety and manual approval central.

Phases

Roadmap phases and success gates

Phase 1

Phase 1: keyboard discovery

Pre-build research

Confirm users want composer-level drafting, not just a better mobile web layout.

User interviews

Friction notes

Permission review

Prototype scope

Success metric: Users identify app switching as the main mobile bottleneck.

Phase 2

Phase 2: controlled insertion prototype

Native prototype

Insert only the selected draft while keeping the final platform post manual.

Keyboard surface

Draft selection

Insert action

Manual posting boundary

Success metric: Prototype users can insert and edit drafts without assuming auto-posting.

Phase 3

Phase 3: Android beta gate

Private beta

Measure whether keyboard usage beats mobile web copy flow for active Android users.

Beta onboarding

Usage analytics

Fallback to mobile web

Roadmap status copy

Success metric: Keyboard users produce more completed manual replies than mobile web-only users.

Risks

Roadmap risks and mitigations

Permission anxiety

Risk: Keyboard permissions can reduce trust.

Mitigation: Explain context and posting boundaries clearly.

Weak context capture

Risk: A keyboard alone may not know enough about the source post.

Mitigation: Use explicit user-provided or shared context.

Premature public launch

Risk: A rough native keyboard can damage trust.

Mitigation: Use private validation first.

Decision gates

What proves the next phase is ready

Build prototype

Mobile web users repeatedly ask for in-app speed.

Expand beta

Users understand insertion vs posting and keep editing manually.

Pause Android keyboard

Permission concerns outweigh app-switching benefits.

FAQ

Roadmap questions

When should Android keyboard work start?

After mobile web share/copy proves repeat mobile demand and users ask for faster in-app replying.

Is Android ReplyPilot Keyboard currently live?

This roadmap describes validation work and should not be treated as current Google Play availability.

What must the keyboard avoid?

It must avoid auto-posting, hidden account access, and confusing insertion with publishing.