Building a WhatsApp-to-CRM product without an unofficial API

The problem

A large share of founder communication happens on WhatsApp, where it normally never reaches the CRM at all. The obvious way to close that gap is an unofficial WhatsApp API: libraries such as whatsapp-web.js or Baileys that speak WhatsApp's protocol directly. That path is fast to build, and it is the behavior that gets phone numbers banned.

The honest framing, stated in the product's own docs, is that WhatsApp automation in general sits in a gray area of WhatsApp's terms of service. Any product built on protocol-level access is betting its users' phone numbers on not being noticed. We were not willing to ship that bet, so the design problem became: capture conversations without any automated behavior to detect.

What we built

A native Mac shell around Apple's WKWebView, the same browser engine that powers Safari, loading the real web.whatsapp.com. To WhatsApp the traffic looks like a person using Safari, because underneath it is exactly that: the official web client, with native conveniences and a CRM sidebar built around it. No unofficial API, no reverse-engineered protocol access, anywhere in the product.

The design premise is that ban risk comes from behavior, not from which app you use, so every interaction stays human-shaped:

• Human-initiated. Nothing happens until you click. No background jobs, no scheduled scraping.
• On-screen only. Capture reads only the chat currently open, when you ask. It never walks the chat list or scrolls back through history on its own.
• You always send. Saved snippets place text into the message box; you press enter. The app never sends a message on your behalf.

This is why the product stays outside the gray area's dangerous end rather than betting on it: the safe behavior is enforced by what the code is able to do, not by a policy promise. The risk is low by construction, not zero, and we say so.

Safety design

The privacy rule that matters most is enforced where it cannot be bypassed. Each conversation has a private/shared toggle, and the check happens on the server, so even a bug in the app could not leak a private chat into the shared CRM. Chats you never sync are never transmitted anywhere; they exist only in your WhatsApp account. The app holds no WhatsApp credentials, and the API token lives in the macOS Keychain rather than in a file.

How the build was run

Two documents did most of the engineering.

The backend contract for the CRM feature was written before either side's code existed: every route the app calls, the exact shape of the data in each direction, and what each error means. The Mac app and the backend were then built against the same document, which is why two separately built halves fit together.

A numbered decision log records every non-obvious choice in three parts: the decision, the reason, and how to reverse it. The log contains a documented reversal, and we point at it deliberately. An early decision tied the app's fake-data switch to its demo switch, which meant demos against a real workspace silently showed canned data and made a broken backend look healthy. A later entry reversed that decision and recorded the failure that forced the change. A decision log that never records a reversal is a diary, not an engineering instrument; the reversal is the evidence the log is load-bearing.

Outcome

The app ships as a signed, notarized DMG, sold at $29 a month, or $9 a month billed yearly; the product page is Backchannel. For our own product we publish process and safety outcomes, not usage metrics.

The transferable part is the posture. Refuse the convenient-but-fragile foundation even when it is your own product on the line, enforce the safety property in code rather than in policy, write the contract before the implementation, and keep a decision log honest enough to contain its own reversals. That is the same posture we bring to client systems, applied where we had every incentive to cut the corner.