WA Scheduler

The problem

It happens to me a lot: I remember I need to write something to someone, but I don’t have a notebook handy. I could jot it in my calendar, but a lot of those things are personal and I don’t want them mixed into my work calendar. The result is predictable: in the morning rush I never get around to opening my personal accounts, and the message never goes out.

WhatsApp has no feature to schedule a message. The apps that claim to solve this automate the send using accessibility permissions to simulate taps — they’re fragile, ask for invasive permissions, and technically violate WhatsApp’s terms of service.

So I built the tool out of my own need, with no business plan behind it. I mentioned it to a couple of friends and they liked it — some started using it. That’s why I’m publishing it: not to sell it from day one, but to validate whether anyone besides me actually has this need.

Building it

V1 — Own design, built with Claude Code (Sept 21–22, 2026)

I defined the flow and screens myself before writing anything: schedule the message, wait, get the notification at the exact time, one tap opens WhatsApp with the chat and text already written, another tap sends it. The core decision was not to automate that last tap — that way the app doesn’t need accessibility permissions or depend on anything fragile. From there I iterated on the process and architecture with Claude, and once that was defined I built the code, the build, and the publishing with Claude too.

• Kotlin + Jetpack Compose — all the UI and interaction.
• Room — local persistence of scheduled messages; nothing is ever sent to a server.
• AlarmManager — fires the notification at the exact time, with a receiver to reschedule after a phone reboot.
• libphonenumber — normalizes numbers from any country to build the correct wa.me link (Argentina and Mexico have their own rules a text split can’t resolve).
• System contact picker — pick a recipient without asking the app for the Contacts permission.
• Visual identity, icon, a permissions onboarding screen with context (why each one is requested), and a specific warning for manufacturers that kill background alarms (Xiaomi, Huawei, Oppo, Vivo, OnePlus).
• Collapsible history, cancel with undo (swipe or button), duplicate an old message to reschedule it.

V2 — Iterating with alpha testers (Sept 23–25, 2026, up to v0.2.7)

Once the first version was up, I put a couple of friends in as testers on the Play Store’s alpha track. Their real-usage suggestions drove the following changes, not a plan set beforehand.

• Recent recipients — its own Room table to pick someone you’ve already written to before, without repeating the contact picker.
• Redesigned the actions on a pending message (cancel, edit, send) and the recipient form, which no longer has a free-text name field: the name only comes from a picked contact.
• 18 languages, defaulting to the device’s language with English as fallback.
• A settings screen accessible at any time (not just on first launch): 12/24h time format and permissions.
• Release signing and a complete Play Store listing (icon, screenshots, description, privacy policy).

Scaling it

There’s no scaling story yet — I’m running technical tests (does the app work well across different phones) and concept tests (does anyone besides my friends actually find it useful) in parallel, not dealing with a volume or cost problem.

What I do know will force a decision if this grows beyond a handful of friends: the planned “3 free pending messages” limit is counted locally on the phone itself, so it resets by clearing the app’s data — an accepted limitation while the cost of a backend isn’t justified.

Regulatory risk: does this violate WhatsApp’s policies?

Before publishing I wanted to seriously check something I’d already suspected since the design phase: that not automating the send wasn’t just a product decision, but the one that keeps me on the allowed side of WhatsApp’s rules. So I reviewed WhatsApp’s official Terms of Service and Messaging Guidelines, not a third-party summary.

The Terms explicitly prohibit “bulk messaging, auto-messaging, auto-dialing, and the like”, “reverse engineer, alter, modify, create derivative works from… our Services”, and “any non-personal use of our Services unless otherwise authorized by us”. The Messaging Guidelines add “use unofficial clients, bulk messaging, auto-messaging, auto-dialing, or automation to harm WhatsApp or our users”.

WA Scheduler builds a wa.me/api.whatsapp.com/send?text=... link and opens it with a standard Android Intent — that’s received by the official WhatsApp app installed on the phone, with the message preloaded in the text box. The person has to tap “Send” themselves, inside WhatsApp. The app never simulates that tap, doesn’t use AccessibilityService, doesn’t reimplement WhatsApp’s protocol, and doesn’t read or write conversations. That ?text= link isn’t a workaround: it’s the mechanism WhatsApp itself documents and publishes for any external app to preload a chat.

The distinction that matters is this: the “unofficial apps” WhatsApp prohibits (WhatsApp Plus, GB WhatsApp, and similar) are clones that replace the real client. WA Scheduler isn’t a WhatsApp client — it’s an app that links out to the real, official client already installed. There’s no auto-messaging (the final send is always manual), no bulk sending (one message, one recipient, one at a time), no unofficial client, and the use case the project itself defines is personal, not mass marketing.

Risk of the number getting blocked: low, on the same order as normal manual WhatsApp use, not that of bulk-sending apps. WhatsApp’s anti-spam systems detect automation patterns (sending speed, many new recipients in a short time, unofficial-client fingerprints) — since every send goes through a real human tap inside the official app, the app doesn’t generate that fingerprint. The one real risk isn’t the app but the usage: scheduling and firing off a huge number of messages to new contacts in a short span could trigger anti-spam, just as it would for anyone typing those same messages by hand.

This gives me a design boundary I intend to preserve on purpose: the day I consider automating the “Send” tap too (for example with accessibility services), that’s the day I cross into auto-messaging and this analysis stops applying. That one manual tap is the line that keeps the app on the allowed side.

Sources consulted: WhatsApp Terms of Service, WhatsApp Messaging Guidelines, Unauthorized use of automated or bulk messaging, About unofficial apps, About WhatsApp and third-party apps, How to use click to chat.

Results

Version / Stage	Period	Result	Cost
V1	Sept 21–22, 2026	Working build, daily personal use	Google Play developer account: $25 (one-time)
V2	Sept 23–25, 2026	v0.2.7, in closed alpha — 7 of 12 testers enrolled (12 are needed for 14 continuous days to move to production)	No additional cost

No consolidated usage metrics yet (downloads, retention): the app isn’t in public production, only in closed testing.

Lessons learned

• A complex need can be 80% solved with a simple solution. Automating the actual WhatsApp send would require creating a Meta account, connecting the number to the WhatsApp Business API, passing verifications, and risking the number getting blocked — all disproportionate to the real problem, which is simply not forgetting to write. Leaving the message ready for one last manual tap is an imperfect solution, but it solves my problem just as well.
• Define the product before delegating the build. I thought through the flow and screens myself, by hand, before touching any code. Only once that was clear did I iterate on the architecture and build everything — code, build, and publishing — together with Claude Code. Separating “what’s needed” from “how it gets built” made the AI part much more precise.