WA Scheduler
De una necesidad personal — no olvidarme de escribirle a alguien — a una app de Android en Play Store, diseñada por mí y construida junto con Claude Code en cuestión de días.
Ver producto →Resumen rápido
- Rol
- Builder solo, construyendo junto con Claude Code como copiloto de desarrollo
- Periodo
- 21 sept 2026 → actualidad (v0.2.7, en alpha cerrada)
- Stack técnico
- Diseño propio del flujo → implementación, build y publicación con Claude Code, sobre Kotlin, Jetpack Compose, Room y AlarmManager
El problema
Me pasa seguido: me acuerdo de que tengo que escribirle algo a alguien, pero no tengo el cuaderno a mano. Lo anoto en el calendario, pero muchas de esas cosas son personales y no las quiero metidas en el calendario del trabajo. El resultado es previsible: en el vértigo de la mañana no llego a entrar a mis cuentas personales, y el mensaje nunca sale.
WhatsApp no tiene una función para agendar un mensaje. Las apps que dicen resolverlo automatizan el envío usando permisos de accesibilidad para simular taps — son frágiles, piden permisos invasivos, y técnicamente violan los términos de servicio de WhatsApp.
Así que hice la herramienta por necesidad propia, sin plan de negocio detrás. Se la comenté a un par de amigos y les gustó — algunos la empezaron a usar. Por eso la estoy publicando: no para venderla desde el día uno, sino para validar si esta necesidad la tiene más gente además de mí.
La construcción
V1 — Diseño propio, build con Claude Code (21–22 sept 2026)
Definí yo mismo el flujo y las pantallas antes de escribir nada: agendar el mensaje, esperar, recibir la notificación a la hora exacta, un tap abre WhatsApp con el chat y el texto ya escritos, otro tap lo envía. La decisión de fondo fue no automatizar ese último tap — así la app no necesita permisos de accesibilidad ni depende de nada frágil. A partir de ahí iteré el proceso y la arquitectura con Claude, y con eso ya definido construí el código, el build y la publicación también con Claude.
- Kotlin + Jetpack Compose — toda la UI e interacción.
- Room — persistencia local de los mensajes agendados; nunca se manda nada a un servidor.
- AlarmManager — dispara la notificación a la hora exacta, con receiver para reprogramar tras un reinicio del teléfono.
- libphonenumber — normaliza números de cualquier país para armar el enlace
wa.mecorrecto (Argentina y México tienen reglas propias que un split de texto no resuelve). - Picker de contactos del sistema — elegir destinatario sin pedirle a la app el permiso de Contactos.
- Identidad visual, ícono, pantalla de onboarding de permisos con contexto (por qué se pide cada uno) y aviso específico para fabricantes que matan alarmas en segundo plano (Xiaomi, Huawei, Oppo, Vivo, OnePlus).
- Historial colapsable, cancelar con deshacer (swipe o botón), duplicar un mensaje viejo para reagendarlo.
V2 — Iteración con testers alpha (23–25 sept 2026, hasta v0.2.7)
Subida la primera versión, puse a un par de amigos como testers en la prueba alpha de Play Store. Sus sugerencias de uso real fueron las que empujaron los cambios siguientes, no un plan armado de antemano.
- Destinatarios recientes — tabla propia en Room para elegir a alguien a quien ya le escribiste antes, sin repetir el picker de contactos.
- Rediseño de las acciones sobre un mensaje pendiente (cancelar, editar, enviar) y del formulario de destinatario, que dejó de tener un campo de nombre libre: el nombre solo llega de un contacto elegido.
- 18 idiomas, con el del dispositivo por defecto e inglés como fallback.
- Pantalla de ajustes accesible en cualquier momento (no solo la primera vez): formato de hora 12/24h y permisos.
- Firma de release y ficha completa de Play Store (ícono, capturas, descripción, política de privacidad).
Escalamiento
Todavía no hay historia de escalamiento — estoy en pruebas técnicas (que la app funcione bien en distintos teléfonos) y de concepto (si a alguien más además de mis amigos le sirve) en paralelo, no en un problema de volumen o costo.
Lo que sí sé que va a pedir una decisión si esto crece más allá de un puñado de amigos: el límite planeado de “3 mensajes pendientes gratis” se cuenta localmente en el propio teléfono, así que se resetea borrando los datos de la app — una limitación aceptada mientras el costo de un backend no se justifique.
Riesgo regulatorio: ¿esto viola las políticas de WhatsApp?
Antes de publicar quise chequear en serio algo que ya intuía desde el diseño: que no automatizar el envío no era solo una decisión de producto, sino la que me mantiene del lado permitido de las reglas de WhatsApp. Así que revisé los Términos de Servicio y las Messaging Guidelines oficiales de WhatsApp, no un resumen de terceros.
Los Términos prohíben explícitamente “bulk messaging, auto-messaging, auto-dialing, and the like”, “reverse engineer, alter, modify, create derivative works from… our Services”, y “any non-personal use of our Services unless otherwise authorized by us”. Las Messaging Guidelines agregan “use unofficial clients, bulk messaging, auto-messaging, auto-dialing, or automation to harm WhatsApp or our users”.
WA Scheduler arma un enlace wa.me/api.whatsapp.com/send?text=... y lo abre con un Intent estándar de Android — eso lo recibe la app oficial de WhatsApp instalada en el teléfono, con el mensaje precargado en el cuadro de texto. La persona tiene que tocar “Enviar” ella misma, dentro de WhatsApp. La app nunca simula ese tap, no usa AccessibilityService, no reimplementa el protocolo de WhatsApp ni lee o escribe conversaciones. Ese enlace con ?text= no es un atajo: es el mecanismo que WhatsApp mismo documenta y publica para que cualquier app externa precargue un chat.
La distinción que importa es esta: las “apps no oficiales” que WhatsApp prohíbe (WhatsApp Plus, GB WhatsApp y similares) son clones que reemplazan el cliente real. WA Scheduler no es un cliente de WhatsApp — es una app que enlaza hacia el cliente real, oficial, ya instalado. No hay auto-messaging (el envío final siempre es manual), no hay bulk (un mensaje, un destinatario, uno a la vez), no hay cliente no oficial, y el uso que define el propio proyecto es personal, no marketing masivo.
Riesgo de bloqueo del número: bajo, del mismo orden que el uso manual normal de WhatsApp, no el de las apps de envío masivo. Los sistemas antispam de WhatsApp detectan patrones de automatización (velocidad de envío, muchos destinatarios nuevos en poco tiempo, huellas de clientes no oficiales) — como cada envío pasa por un tap humano real dentro de la app oficial, la app no genera esa huella. El único riesgo real no es la app sino el uso: agendar y disparar muchísimos mensajes a contactos nuevos en un lapso corto puede llamar la atención del antispam, igual que le pasaría a cualquiera escribiendo esos mismos mensajes a mano.
De acá sale un límite de diseño que pienso preservar a propósito: el día que se me ocurra automatizar también el tap de “Enviar” (por ejemplo con accessibility services), ahí sí cruzo a auto-messaging y este análisis deja de aplicar. Ese único tap manual es la frontera que mantiene a la app del lado permitido.
Fuentes consultadas: Términos de Servicio de WhatsApp, Messaging Guidelines de WhatsApp, Uso no autorizado de mensajería automática o masiva, Acerca de las apps no oficiales, Acerca de WhatsApp y las apps de terceros, Cómo usar la función de clic para chatear.
Resultados
| Versión / Etapa | Periodo | Resultado | Costo |
|---|---|---|---|
| V1 | 21–22 sept 2026 | Build funcional, uso personal diario | Cuenta de desarrollador Google Play: $25 (pago único) |
| V2 | 23–25 sept 2026 | v0.2.7, en alpha cerrada — 7 de 12 testers inscritos (se necesitan 12 durante 14 días continuos para pasar a producción) | Sin costo adicional |
Sin métricas de uso consolidadas todavía (descargas, retención): la app no está en producción pública, solo en prueba cerrada.
Aprendizajes
- Una necesidad compleja se puede resolver al 80% con una solución simple. Automatizar el envío real de WhatsApp exigiría crear cuenta en Meta, conectar el número a la API de WhatsApp Business, pasar verificaciones, y correr el riesgo de que bloqueen el número — todo eso desproporcionado frente al problema real, que es simplemente no olvidarme de escribir. Dejar el mensaje listo para un último tap manual es una solución imperfecta, pero me resuelve el problema igual de bien.
- Definir el producto antes de delegar la construcción. El flujo y las pantallas los pensé yo, a mano, antes de tocar código. Recién con eso claro iteré la arquitectura y construí todo — código, build y publicación — junto con Claude Code. Separar “qué hace falta” de “cómo se construye” hizo que la parte de IA fuera mucho más precisa.