Build vs buy for live chat on a marketing site

Teams often estimate “two weeks for a chat bubble.” That covers UI. It rarely covers visitor tokens, domain locking, rate limits, encrypted bot credentials, signed outbound webhooks, durable message logs, and the on-call burden when Slack’s API hiccups on a Friday launch.

This decision guide is for product engineers and founders choosing whether to build live chat infrastructure or buy a narrow tool. It is not a generic Intercom teardown with invented competitor prices.

Quick answer

• Buy when the job is “visitor asks, team answers where they already work.”
• Build when chat is the product itself—routing engines, knowledge bases, multi-brand suites.
• Hidden build costs: abuse, identity, realtime fan-out, credential storage, retries, and compliance paperwork.
• CanWeChat fits the buy case for one site, one reply destination, small widget, $19/month after a 3-day trial.
• Skip CanWeChat if you need enterprise helpdesk depth or simultaneous multi-channel reply.

The two-week illusion

A bubble and a textarea are a weekend. Production chat is a distributed system with a friendly face. You need at least:

• Anonymous visitor sessions that survive refresh without leaking other people’s history.
• Optional identify() after your app login so agents see real customers.
• Origin/domain allowlists so scraped public keys are useless on random hosts.
• Rate limits and basic spam controls on public POST endpoints.
• A message store with retention and export/delete paths.
• Realtime or near-realtime delivery to agents without melting your origin.
• Outbound integration workers with retries and dead-letter handling.
• Secret handling for Slack/Discord/Telegram tokens—encryption, rotation, audit.
• Billing entitlement that does not trust browser redirects.

Each bullet is a week when you include tests, abuse cases, and documentation. Multiplying optimistic UI estimates by four is still kind.

Decision table

• Choose build if chat quality is a core differentiator and you will staff it for years.
• Choose buy-narrow (CanWeChat-shaped) if you need a messenger into Slack/Discord/Telegram/inbox with minimal embed weight.
• Choose buy-suite (helpdesk-class) if you need macros, complex assignment, multi-brand inboxes, and large seat graphs—and you accept heavier widgets and pricing.
• Choose “mailto and Calendly” if volume is tiny and chat would create false urgency.

Criteria that actually matter for marketing-site chat

1. Install complexity and widget weight on Core Web Vitals.
2. Where replies land (inbox vs tools the team already opens).
3. Per-seat vs per-site pricing predictability.
4. Webhooks for your CRM without scraping a vendor inbox UI.
5. Domain lock and signing posture.
6. Honest limitations written in public docs.

What building on Workers really means

CanWeChat’s own stack is a useful reference for DIY cost: Cloudflare Workers at the edge, D1 for durable conversation rows, Durable Objects for realtime sockets, and queues for integration fan-out. That combination is excellent—and still non-trivial to operate. You will invent schema migrations, idempotent Slack event handling, HMAC verification, SSRF protections on customer webhook URLs, and a dashboard for non-engineers to rotate secrets.

Cost sketch (illustrative, not a quote)

A single engineer-month is often more expensive than a year of a narrow SaaS seat-or-site plan. DIY still wins when chat is strategic IP. For a marketing site capturing sales questions, the marginal value of owning WebSocket reconnect logic is usually zero.

• CanWeChat Pro: $19/month, one site, one active reply destination, 3-day free trial.
• DIY: engineering time + on-call + vendor APIs (Slack, email OTP, payments) + incident cost when embeds break Core Web Vitals before a launch.
• Helpdesk suites: typically higher when seats and add-ons accumulate—verify current pricing on vendor sites the day you decide; we will not invent numbers here.

Hybrid paths that usually work

Buying the messenger does not mean abandoning your systems of record. Use CanWeChat’s signed webhook relay to append notes to your CRM, trigger internal alerts, or open tickets in a tool you already operate. Keep human replies in Slack (or inbox) where latency is social, not architectural.

What rarely works: building a custom bubble “just for branding,” then bolting on Slack, then discovering you still need domain lock, identify, and retries. At that point you have rebuilt the buy case with none of the operational maturity.

Where CanWeChat sits

CanWeChat is intentionally narrow: small Shadow DOM widget, public install + Widget API + webhook docs, dashboard for humans, Dodo webhook-based billing, signed outbound relays. It is the buy case for small teams—not a replacement for Intercom-scale support orgs.

Who should not choose CanWeChat

• Teams that need multi-brand inboxes and elaborate routing.
• Orgs that require SOC 2 reports before any vendor—we do not claim SOC 2 here.
• Products where the chat experience itself is the differentiator and must be fully custom.
• Companies that need several reply destinations hot at once.

Being clear about non-fit is part of SEO quality and part of not wasting a founder’s week. If your RFP requires guaranteed response-time SLAs, multi-seat analytics packs, or a compliance binder on day one, shortlist a helpdesk suite and keep CanWeChat out of the bake-off.

Build-vs-buy checklist

1. Write the job story in one sentence (visitor → team tool).
2. List must-have integrations and whether simultaneous destinations are required.
3. Budget engineer-weeks for abuse, identity, and retries—not just UI.
4. Prototype the embed weight on a real landing page.
5. Decide retention, export, and delete obligations before storing messages.
6. If the story is “answer in Slack,” try a narrow buy before building Workers glue.

If that checklist points to a narrow messenger, start a trial, lock domains, and measure whether your team actually answers faster—not whether you enjoyed writing a WebSocket server.