The Handshake with an Expiration Date

A short email from my business partner. A forwarded newsletter — a competitor's changelog. They'd shipped WhatsApp notifications. Automated reminders fired straight from photographers' personal numbers.

Can we build this?

I assumed Meta had an official API for this. They don't. The only legitimate path is the WhatsApp Business API — a separate product with its own phone numbers, its own requirements.

The competitor wasn't using that. They were impersonating WhatsApp Web to automate personal accounts.

Open-source libraries make this trivial. Multiple SaaS products ship it. It's a door everyone walks through without checking if it's actually a door.

It violates Meta's Terms of Service.

I found the libraries. I figured out how to build it. I brought it to my partner: we could ship this, but we'd be climbing a ladder we don't own.

His first reaction: "That's a great feature." He's right — photographers' clients live on WhatsApp.

But I kept thinking about what happens after.

That question — what happens after — is where most teams go wrong. Not because they're reckless, but because they're asking the wrong question.

The question isn't "Can we build it?"

It's: "What happens to our customers the day this breaks?"

Not if. When. The only question is whether you're standing next to your customers when it happens — or hiding behind a changelog.

This isn't hypothetical. It already happened.

Anthropic recently killed the ability to use Claude Pro subscriptions through third-party tools. Developers had been routing consumer accounts through clients that impersonated the official one. It was cheap, powerful, perfect — until one morning it wasn't.

Users woke up to: "This credential is only authorized for use with Claude Code." No warning. No migration path. Telegram bots, agent loops, automation pipelines — gone in a single deploy.

Now imagine that, but your customers' businesses depend on it.

Here's how that plays out with WhatsApp.

A developer gets the task. Build WhatsApp notifications. A quick search turns up the libraries — open-source, well-documented, battle-tested by other SaaS products. An afternoon of work. Ship it on Friday, customers love it by Monday.

Those customers start leaning on it. Their clients stop checking email because the WhatsApp reminder is right there — pinging them like a tap on the shoulder.

Then Meta changes a header. Tweaks an auth flow. Something invisible that breaks everything visible.

Now you're on a call with a photographer explaining that the feature their clients depended on... evaporated.

Customers don't remember "they used an unofficial API." They remember you promised something and pulled it out from under them.

We said no.

We already had email notifications. WhatsApp would've been nice-to-have. Saying no meant we didn't swallow a grenade and call it lunch.

That one no became a filter. Now every feature decision passes through one question: will we be able to support this long-term? We're building a platform meant to last years — that question keeps us honest.

Some customers respect that. They'll point to a competitor's feature we lack, we'll explain why we walked away, and that conversation builds something a feature checklist can't.

Competitors shipping unofficial integrations are building on a fault line. The more customers depend on it, the bigger the crack when it breaks — and it will. Those customers will look for solid ground. They'll find the companies that didn't gamble with their trust.

Restraint is an underrated competitive advantage.

If your product depends on a loophole, it's not innovation. It's a handshake with an expiration date.