WA Scheduler
De uma necessidade pessoal — não esquecer de escrever para alguém — a um app de Android na Play Store, projetado por mim e construído junto com o Claude Code em questão de dias.
Ver produto →Resumo rápido
- Função
- Builder solo, construindo junto com o Claude Code como copiloto de desenvolvimento
- Período
- 21 de set. de 2026 → atualidade (v0.2.7, em alpha fechado)
- Stack técnico
- Design próprio do fluxo → implementação, build e publicação com o Claude Code, sobre Kotlin, Jetpack Compose, Room e AlarmManager
O problema
Isso acontece comigo com frequência: lembro que preciso escrever algo para alguém, mas não tenho o caderno à mão. Anoto no calendário, mas muitas dessas coisas são pessoais e eu não quero misturá-las com o calendário do trabalho. O resultado é previsível: na correria da manhã não consigo abrir minhas contas pessoais, e a mensagem nunca sai.
O WhatsApp não tem uma função para agendar uma mensagem. Os apps que dizem resolver isso automatizam o envio usando permissões de acessibilidade para simular toques — são frágeis, pedem permissões invasivas e tecnicamente violam os termos de serviço do WhatsApp.
Então eu criei a ferramenta por necessidade própria, sem plano de negócio por trás. Comentei com alguns amigos e eles gostaram — alguns começaram a usar. Por isso estou publicando: não para vender desde o primeiro dia, mas para validar se mais alguém além de mim tem essa necessidade.
A construção
V1 — Design próprio, build com o Claude Code (21–22 de set. de 2026)
Defini eu mesmo o fluxo e as telas antes de escrever qualquer coisa: agendar a mensagem, esperar, receber a notificação na hora exata, um toque abre o WhatsApp com o chat e o texto já escritos, outro toque envia. A decisão de fundo foi não automatizar esse último toque — assim o app não precisa de permissões de acessibilidade nem depende de nada frágil. A partir daí iterei o processo e a arquitetura com o Claude, e com isso já definido construí o código, o build e a publicação também com o Claude.
- Kotlin + Jetpack Compose — toda a UI e interação.
- Room — persistência local das mensagens agendadas; nada é enviado a um servidor.
- AlarmManager — dispara a notificação na hora exata, com um receiver para reprogramar depois de uma reinicialização do celular.
- libphonenumber — normaliza números de qualquer país para montar o link
wa.mecorreto (Argentina e México têm regras próprias que uma divisão de texto não resolve). - Seletor de contatos do sistema — escolher o destinatário sem pedir ao app a permissão de Contatos.
- Identidade visual, ícone, tela de onboarding de permissões com contexto (por que cada uma é pedida) e aviso específico para fabricantes que matam alarmes em segundo plano (Xiaomi, Huawei, Oppo, Vivo, OnePlus).
- Histórico recolhível, cancelar com desfazer (swipe ou botão), duplicar uma mensagem antiga para reagendá-la.
V2 — Iteração com testers alpha (23–25 de set. de 2026, até a v0.2.7)
Depois de subir a primeira versão, coloquei alguns amigos como testers no teste alpha da Play Store. As sugestões de uso real deles impulsionaram as mudanças seguintes, não um plano montado com antecedência.
- Destinatários recentes — tabela própria no Room para escolher alguém para quem você já escreveu antes, sem repetir o seletor de contatos.
- Redesign das ações sobre uma mensagem pendente (cancelar, editar, enviar) e do formulário de destinatário, que deixou de ter um campo de nome livre: o nome só vem de um contato escolhido.
- 18 idiomas, com o do dispositivo como padrão e inglês como alternativa.
- Tela de ajustes acessível a qualquer momento (não só na primeira vez): formato de hora 12/24h e permissões.
- Assinatura de release e ficha completa na Play Store (ícone, capturas de tela, descrição, política de privacidade).
Escalonamento
Ainda não há uma história de escalonamento — estou em testes técnicos (o app funcionar bem em celulares diferentes) e de conceito (se mais alguém além dos meus amigos acha isso útil) em paralelo, não em um problema de volume ou custo.
O que eu sei que vai exigir uma decisão se isso crescer além de um punhado de amigos: o limite planejado de “3 mensagens pendentes grátis” é contado localmente no próprio celular, então ele reseta ao apagar os dados do app — uma limitação aceita enquanto o custo de um backend não se justificar.
Risco regulatório: isso viola as políticas do WhatsApp?
Antes de publicar, eu quis checar a sério algo que já suspeitava desde o design: que não automatizar o envio não era só uma decisão de produto, mas a que me mantém do lado permitido das regras do WhatsApp. Então revisei os Termos de Serviço e as Messaging Guidelines oficiais do WhatsApp, não um resumo de terceiros.
Os Termos proíbem explicitamente “bulk messaging, auto-messaging, auto-dialing, and the like”, “reverse engineer, alter, modify, create derivative works from… our Services”, e “any non-personal use of our Services unless otherwise authorized by us”. As Messaging Guidelines acrescentam “use unofficial clients, bulk messaging, auto-messaging, auto-dialing, or automation to harm WhatsApp or our users”.
O WA Scheduler monta um link wa.me/api.whatsapp.com/send?text=... e o abre com um Intent padrão do Android — isso é recebido pelo app oficial do WhatsApp instalado no celular, com a mensagem pré-carregada na caixa de texto. A pessoa precisa tocar em “Enviar” ela mesma, dentro do WhatsApp. O app nunca simula esse toque, não usa AccessibilityService, não reimplementa o protocolo do WhatsApp nem lê ou escreve conversas. Esse link com ?text= não é um atalho: é o mecanismo que o próprio WhatsApp documenta e publica para que qualquer app externo pré-carregue um chat.
A distinção que importa é esta: os “apps não oficiais” que o WhatsApp proíbe (WhatsApp Plus, GB WhatsApp e similares) são clones que substituem o cliente real. O WA Scheduler não é um cliente do WhatsApp — é um app que direciona para o cliente real, oficial, já instalado. Não há auto-messaging (o envio final sempre é manual), não há bulk (uma mensagem, um destinatário, um de cada vez), não há cliente não oficial, e o uso que o próprio projeto define é pessoal, não marketing em massa.
Risco de bloqueio do número: baixo, da mesma ordem do uso manual normal do WhatsApp, não o de apps de envio em massa. Os sistemas antispam do WhatsApp detectam padrões de automação (velocidade de envio, muitos destinatários novos em pouco tempo, marcas de clientes não oficiais) — como cada envio passa por um toque humano real dentro do app oficial, o app não gera essa marca. O único risco real não é o app, mas o uso: agendar e disparar muitíssimas mensagens para contatos novos em um período curto pode chamar a atenção do antispam, assim como aconteceria com qualquer pessoa digitando essas mesmas mensagens à mão.
Daqui sai um limite de design que pretendo preservar de propósito: no dia em que eu cogitar automatizar também o toque de “Enviar” (por exemplo com accessibility services), aí sim eu cruzo para auto-messaging e essa análise deixa de valer. Esse único toque manual é a fronteira que mantém o app do lado permitido.
Fontes consultadas: Termos de Serviço do WhatsApp, Messaging Guidelines do WhatsApp, Uso não autorizado de mensagens automáticas ou em massa, Sobre apps não oficiais, Sobre o WhatsApp e apps de terceiros, Como usar o recurso clique para conversar.
Resultados
| Versão / Etapa | Período | Resultado | Custo |
|---|---|---|---|
| V1 | 21–22 de set. de 2026 | Build funcional, uso pessoal diário | Conta de desenvolvedor do Google Play: $25 (pagamento único) |
| V2 | 23–25 de set. de 2026 | v0.2.7, em alpha fechado — 7 de 12 testers inscritos (são necessários 12 durante 14 dias contínuos para passar para produção) | Sem custo adicional |
Ainda sem métricas de uso consolidadas (downloads, retenção): o app não está em produção pública, apenas em teste fechado.
Aprendizados
- Uma necessidade complexa pode ser resolvida em 80% com uma solução simples. Automatizar o envio real pelo WhatsApp exigiria criar conta na Meta, conectar o número à API do WhatsApp Business, passar por verificações, e correr o risco de o número ser bloqueado — tudo isso desproporcional diante do problema real, que é simplesmente não esquecer de escrever. Deixar a mensagem pronta para um último toque manual é uma solução imperfeita, mas resolve meu problema igual de bem.
- Definir o produto antes de delegar a construção. Pensei o fluxo e as telas eu mesmo, à mão, antes de tocar em código. Só depois disso estar claro é que iterei a arquitetura e construí tudo — código, build e publicação — junto com o Claude Code. Separar “o que é necessário” de “como se constrói” fez com que a parte de IA fosse muito mais precisa.