WhatsApp WarmUp

01 — The problem

A newly provisioned WhatsApp number that goes straight into production use looks like a bot and gets treated like one. Numbers need weeks of ordinary, human-looking activity before they're trusted — and doing that by hand means someone texting between phones on a schedule, every day, for three weeks.

The second problem showed up after the first was solved: an automation that runs invisibly might as well not be running. Log lines prove nothing to anyone but the person who wrote them.

02 — Constraints

• The messaging surface is unofficial — headless browser sessions that drop, re-authenticate by QR code, and break in ways an API never would. Session management is half the product.
• Pacing has to look human: daily message targets that ramp week over week (90–120, then 120–190, then 190–250), two to seven sessions a day inside a fixed local-time window, and randomized delays between messages.
• Conversations can't repeat. Scripted lines get recognizable; every session needs fresh material.
• Self-hosted on a VPS by choice — full control, low cost, and every security consequence of being your own ops team.

03 — The approach

A scheduler plans each day from the ramp program — how many sessions, when, and how many messages each — with jitter on everything. Claude generates each session's conversation fresh, so no two sessions read alike. An account manager holds up to ten numbers with per-number session state, tags, and connect/disconnect handling.

The part that changed who could use it: a Live view that renders the warm-up as a WhatsApp-style group chat in real time — messages flowing, members joining, admins being set. Anyone with SSO access can open it and know in five seconds that the system is alive, without reading a single log line.

The build itself ran on a phase-gate process: a single scope document as the source of truth, work shipped one verified phase at a time, and adversarial review passes before each merge. Most of the code was written by AI under that discipline — which is the point: the rigor lives in the process, not in who types.

04 — The outcome

The 21-day program runs unattended inside its daily window — planned, executed, and visible live to anyone on the dashboard. Adding a number to the fleet is a QR scan. What was a manual daily chore became something the team watches, not something they do.

05 — What I'd do differently

Build the Live view first, not last. The engine ran for weeks with only log lines proving it worked — fine for me, useless for everyone else — and the observability that made the tool shareable was retrofitted. Same lesson on the infrastructure side: the full server-hardening stack (default-deny firewall, fail2ban, egress monitoring, scheduled scans) earned its place over time, and next time it goes in on day one, before anything is exposed.