# should you build your own chat widget? Your agent can build a chat widget before lunch. Here is everything it has to do after lunch, from reconnects and spam to Slack threads, 12 languages and GDPR. 2026-10-15 ยท Kuba Yes, you can build a chat widget yourself. Your agent will have a bubble on your page before lunch, and it will look great. This post is about what comes after lunch: the list of things a chat widget has to get right before you'd trust it with a real customer. We know the list because we built all of it. It's longer than it looks. ## the afternoon Here's the version everyone builds first. A button in the corner. A panel with an input. A websocket to your server. A Slack bot that posts the message to a channel. You type "hi" on localhost, it shows up in Slack, you feel great. That's real progress, and it's about 10% of a chat widget. The other 90% only shows up when real visitors, real phones and real teammates use it. None of it is hard on its own. There's just a lot of it, and each piece fails in a way you only find in production. ## the widget has to live on someone else's page Your widget doesn't run on a blank page. It runs inside a site with its own CSS, its own fonts, its own scripts and its own idea of what `button` looks like. - **Isolation.** The host page's styles must not leak into your panel, and yours must not leak out. That means Shadow DOM, and learning which things it doesn't isolate. - **Weight.** Everything you load before the click is paid by every visitor, including the many who never open the chat. Spookat loads one file of about 2 kb before anyone clicks, and nothing else. - **Phones.** The keyboard covers the input. iOS zooms into any input under 16 px. The launcher sits on top of the store's "add to cart" bar. Each of these is an afternoon to notice and another to fix without breaking desktop. - **Accessibility.** Keyboard users need to reach it, open it, type, and close it with focus returning to where they were. Screen readers need to hear new replies. Our widget passes axe with zero findings; getting there is a checklist, not a vibe. - **Looks.** Your site isn't brutal-green like ours. So you need styles, fonts, an accent color, left or right, a label. We ship 8 styles and 17 fonts, and each one has to work on every screen size. - **Languages.** Your visitors don't all read English. Spookat's widget speaks 12 languages, including the ones where "you" has a formal and an informal form and you have to pick. ## the connection has to survive real life On localhost, the websocket never drops. On a train, it drops every tunnel. - **Reconnecting** without hammering your server when a whole city comes back online at once. - **Messages typed while offline** have to wait and go out once the connection is back. - **Nothing sent twice.** A message sent right as the connection dropped may or may not have arrived. Your widget can't know, so every message needs an id your server can recognise on the second try. - **Replies that arrived while the visitor was gone** have to show up when they're back, in order. It's one of the quieter parts of the product and one of the most important. ## slack is the easy part, until it isn't Posting a message to Slack takes one API call. Running support from Slack takes a lot more. - **One thread per conversation,** so replies go to the right visitor and not to whoever wrote last. - **Teammates' names.** Visitors should see "Anna", not "spookat-bot". Every teammate needs a name, and a way to hide it. - **Slack's rate limits.** Slack accepts about one message per second per channel. A busy Monday needs a queue that respects that without losing anything. - **Discord too,** if your community lives there. It's a different API, a different gateway and different limits. ## a visitor who left still wants the answer Most visitors ask and leave. If your reply lands after they closed the tab, it lands nowhere. Spookat can email the reply, in the visitor's language, sent in your name, with a way to stop the emails. That's email deliverability, templates in 12 languages and an unsubscribe flow, just for the case where nobody's watching. ## bots will find it A public text box on a public page gets found. Within weeks you'll see spam, then floods. You need limits that stop a bot without stopping a real visitor mid-conversation, and they have to be per site, so one noisy site never slows down another. In our load test, one flooded site was held back while every other site carried on as if [nothing happened](/blog/1000-messages-a-second/). ## the boring part is the legal part A chat widget collects personal data. So you need a privacy page that says exactly what you store, a data processing agreement for your business customers, a list of subprocessors, a retention period, a way to delete a conversation, and a way to export everything. We never store an IP address and the widget sets no cookies, so it doesn't need a cookie banner. Designing it that way is a decision you make on day one, not a feature you add later. ## and then it has to keep working Everything above is the build. After that comes the part nobody schedules: - Slack, Discord and browsers change their APIs and their rules. - Backups, monitoring and someone who notices at 3am. - Your teammates want an inbox for when they're not in Slack, roles for who can change settings, and a log of who did what. - Your agent wants an API, webhooks and an MCP server so it can help answer. Every item on this page is something we built, tested and now maintain. It's the unglamorous 90%, and it's why the widget still looks simple. ## when building it yourself makes sense There are good reasons to build your own. If chat is the core of your product, own it. If you need a flow no widget offers, like a support chat wired into your own ticketing rules, build that part. If you're learning, a chat widget is a fantastic project: websockets, a bot, a bit of UI, real users. The question is only whether you want to own the other 90% for years. For most teams, the answer is that they'd rather ship the thing their customers pay for, and have a chat that already works. ## the honest math Count the hours you'd spend on the list above, then multiply by what an hour of your time is worth. Spookat is $4.99 a site a month, for the whole team, with 14 days free and no card. If building a chat widget is your product, build it. It's a great problem. If your product is something else, spend the afternoon on that instead. [See what's included](/pricing/). --- source: https://spookat.com/blog/build-your-own-chat-widget/