Can I vibecode Eloqra?

What you build

One script tag injects a chat widget into your site, messages arrive in your Telegram, and replying to the bot message replies to the visitor · one conversation at a time.

what you need

• a Telegram bot token from @BotFather
• an HTTPS host for the websocket · Telegram will not load a Mini App over plain http
• BotFather registration of the Mini App URL and menu button, if you want a real inbox rather than bot replies

The chat is an evening · the Telegram operator console is the part that eats the weekend, and it's free for one site anyway.

The prompt

A weekend with a coding agent. The gaps that stay are right below, under “what you lose”.

Build me a self-hosted live-chat widget whose inbox is Telegram. Requirements:

- Stack: a single Node + TypeScript service (Fastify) with SQLite via better-sqlite3.
  No Docker, no separate frontend build, no accounts system.
- Embeddable widget: GET /widget.js returns a script that injects a launcher button and
  chat panel into any page via one tag with data-site-id, rendered in a shadow DOM so the
  host page's CSS can't leak in. No iframe. Read theme (light/dark), accent color, and
  corner position from data- attributes.
- Transport: a websocket (ws) between visitor and server, with a long-poll fallback when
  the socket won't open. Persist every message. Give the visitor a signed cookie id so
  their thread survives a reload.
- On a conversation's first message, capture page URL, referrer, and user agent parsed to
  device/browser/OS, plus coarse IP geolocation from a free API.
- Telegram: a grammY bot posts each new conversation to OWNER_CHAT_ID with that visitor
  context. The operator answers using Telegram's native reply-to-message · map the
  replied-to message id back to its conversation and push the text to the visitor live.
- Typing indicators in both directions, and an optional pre-chat form (name + email)
  toggled per site.
- An /admin page behind basic auth listing conversations, each full thread, and a reply box,
  so the widget still works when Telegram is unreachable.
- Secrets in .env: BOT_TOKEN, OWNER_CHAT_ID, ADMIN_PASSWORD, ALLOWED_ORIGINS for CORS.
- Ship a README with the exact snippet to paste and VPS deploy steps (systemd + Caddy for
  TLS, since websockets need it).
- Deliberately out of scope: a phone operator console. That is a Telegram Mini App, a
  second project with its own rules (initData HMAC auth, viewportStableHeight sizing,
  safe-area insets); budget separate days for it. Also out: multiple operators,
  billing, canned replies, AI autoresponders, and analytics dashboards.

What you lose

• a real operator inbox · the Mini App console with a combined thread list across sites, unread badges, typing indicators and deep links from a notification straight into the conversation · bot replies cover one chat at a time, not five at once
• the week you spend learning Telegram's webview rather than writing features · initData HMAC auth, sizing from viewportStableHeight because dvh overshoots, two safe-area insets to stay clear of the status bar in fullscreen, and text selection disabled so copying a message needs a hand-rolled long-press
• a free tier · you would be spending days plus a monthly VPS bill to replace something that costs nothing for one site
• everything that isn't the happy path · socket reconnects, duplicate sends, message ordering on flaky mobile networks, Telegram rate limits and retry queues, bot token rotation
• always-on hosting · your widget is dead whenever your box, your TLS cert, or your websocket is, and a chat that silently stops connecting reads to visitors as you ignoring them

Why people still pay

Mostly they don't · for one website there is nothing to pay. Free is forever, with unlimited conversations, the full Telegram inbox and mini-app, and every widget option; 4.99 buys an extra project slot for a second site and nothing more, and the 'powered by' badge appears on paid tiers too. So the usual death-list logic inverts here. You aren't weighing a weekend against a subscription, you're weighing a weekend plus a VPS, TLS renewals, reconnect logic, and Telegram retry handling against zero. Live chat is also a promise that someone is actually there, which makes it a bad thing to hang off a box you maintain between other work. The one honest reason to build your own: you want visitor conversations on your own hardware instead of someone else's. That is the entire argument, and it isn't a financial one.

moat: Infrastructure scale Execution quality what a moat is

free tier/platform friction/hosting

Free alternatives

Not in the mood to build it? These already exist, they are free or open source, and we checked them one by one.

Who has already built it

Starting from here is still vibecoding: the prompt is for when you want it exactly your way.

• Chatwoot (opens in a new tab) — self-hostable customer engagement suite · far heavier, but open source and battle-tested

Do you agree?