Should I vibe code
Provide reliable website chat with routing, transcripts, and canned replies
Nobody sees the routing bug. The customer just waits, decides you are closed, and buys somewhere else.
?
Their verdict, the Starter price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-04.
?
Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.
The honest answer
why the verdict is what it is
The Crisp entry argues the widget half — a script you serve onto your own checkout — and every word of it applies here, so read that first. What LiveChat adds is the part nobody costs: this is staffing software. Routing rules, groups, per-agent chat limits, transfers that carry the transcript, supervision, ratings, and an availability model that has to be right. The chat box is an afternoon. The dispatcher behind it is the product, and its bugs do not throw: when your presence logic believes an agent is online because a browser tab is open in an empty flat, nothing errors, no alert fires, and a customer simply sits there until they decide you are closed.
What actually breaks
not "if". the specific failures.
- Presence. An agent shuts the laptop, the socket dies without a close frame, and your dispatcher keeps handing conversations to a seat nobody is sitting in
- Assignment under concurrency — two agents opening the same incoming chat, or a queue routed to a group where everyone is already at their limit and nothing says so
- Transfers that drop the transcript, so the customer explains the whole thing again to the second person and rates the conversation accordingly
- Agent accounts. Roles, groups and a supervision view mean anyone with a login can read every conversation the company has ever had, which is a permissions model you now own
- Canned responses and tags: trivial to build, skipped in the first version, and the reason the team quietly goes back to answering from a shared inbox
- The report your manager asks for in week four — first response time, by agent, by hour — computed from lifecycle events you never stored
A Friday promotion goes well enough that eleven chats arrive in four minutes. Round-robin hands a third of them to a colleague who left at five with the tab open, so those conversations are assigned to a browser in an empty flat. Nothing errors. The dashboard is green, the socket is technically connected, and an unread badge climbs on a machine nobody is looking at. Monday morning you find seven unanswered conversations, timestamped to the minute, two of them people asking whether their order actually went through. The refunds are the cheap part. The screenshot of your unanswered chat window, posted publicly, is not.
Is that you?
the verdict is a default, not a law
- One person answers, there is no queue, and "routing" means the message lands in your own inbox
- It is internal — staff to staff, behind a login that already exists
- Every conversation falls back to email within minutes, so the worst case is a late reply rather than no reply
- You have a second agent, which is the moment you are writing a dispatcher, a presence model and a permissions system
- The widget would load on a page where people are about to pay
- A missed chat costs a sale or somebody’s afternoon
- You could not produce last week’s first-response times from the data you already store
If you build it anyway
the checklist, then the prompt that enforces it
- Model availability as explicit state with a heartbeat, and expire it. Presence inferred from an open socket is a lie the first time a laptop lid closes.
- Assign each conversation exactly once, inside a transaction with a row lock. Two agents in one chat is the first bug this class of app ships.
- Give every queued conversation a deadline and an escalation. Nothing may sit in a queue with nobody accountable for it.
- Build the email fallback before the realtime layer, so an outage degrades to "we replied later" instead of silence.
- Store lifecycle events — enqueued, assigned, first agent reply, transferred, closed — from the first commit. First response time cannot be backfilled.
- Transfers carry the transcript and the visitor identity, or they are not transfers.
- Redact card-shaped and national-id-shaped strings on write. Support transcripts are where card numbers end up, and backups copy them faster than you can delete them.
I am building live chat with multiple agents for my own website. The dispatcher is the dangerous half, not the chat box. Apply these before any feature work.
1. Agent availability is explicit state driven by a heartbeat, never "the
socket is open". If the heartbeat stops for 30 seconds, mark the agent
away and reassign their unanswered queue.
2. Assign a conversation exactly once, in a transaction with a row lock, and
show me that query. Two agents in the same chat is the first bug here.
3. Every queued conversation carries a deadline. If nobody is assigned, or no
agent has replied by it, escalate to the whole group and then to email.
A conversation may never sit unanswered with nobody accountable.
4. Build the email fallback path before the websocket layer.
5. Emit and persist lifecycle events from the first commit: enqueued,
assigned, first agent message, transferred, closed. I will be asked for
first response time and it cannot be reconstructed later.
6. A transfer moves the full transcript and visitor identity with it.
7. Agent accounts get roles, not an is_admin boolean. Decide who may read
other people’s conversations before building the supervision view.
8. Redact card-shaped and national-id-shaped strings before a message is
written to the database. Once stored it is also in every backup.
9. The visitor endpoint is public: rate limit per IP and per visitor id, cap
message size, and challenge on burst, before launch rather than after.
10. Messages send over ordinary HTTP with a client-generated idempotency key;
the socket only delivers updates. A dropped socket must not eat a
question or send it twice.
11. Out of scope, and say so rather than faking it: chatbots, WhatsApp and
SMS channels, co-browsing, and any reporting beyond those events. If I
am staffing this with a real team, tell me to go and price LiveChat.That one keeps you out of trouble. For the prompt that actually builds it, canivibecodeit.com has one.
their build prompt ↗Or don’t build it
the boring option, and the way back out
The second agent. One person answering chats can be a form and an inbox; two people need routing, availability, transfer and a supervisor view, and that is the whole product you would be writing. At $25 per person month-to-month it costs less than the first weekend, and Chatwoot self-hosted is the free middle if you want the transcripts on your own disk without writing the dispatcher yourself.
$25/mo is cheaper than your weekend.
Transcripts export as JSON keyed by a stable conversation id, with agent ids, visitor ids and timestamps intact — that is exactly the shape Chatwoot, LiveChat and Help Scout want on import. Canned responses and tags come across as a flat list. The part that does not move is the operational history: if you never stored assignment and first-reply events, your new tool starts its reporting from zero.
Mature open-source shared inbox and live chat, with the routing, agent roles and widget already built.
Open-source live chat in Elixir, now explicitly in maintenance mode — a fair preview of how long enthusiasm lasts here.
Questions
How is this different from the Crisp entry?
Crisp is about the widget: a script you serve onto your own pages, next to your payment form. This one is about the other side of the glass. LiveChat is priced per agent because what you are buying is the machinery that decides which human gets which conversation and what happens when none of them do.
What actually goes wrong first?
Presence. Every naive implementation treats an open websocket as "this person is available", and browsers keep sockets alive through lid closes, backgrounded tabs and sleeping laptops. The queue keeps routing, nothing throws, and the failure is only visible from the customer’s side.
Is a contact form that creates an email good enough?
For a lot of small teams, yes, and it removes every risk on this page. What you give up is the reply while the customer is still on the site — which is the only reason live chat converts, and precisely the part that costs money to operate.
Every week, someone ships something they shouldn’t have.
New verdicts, the worst thing that landed in the trap, and the occasional incident report. No other email, ever.
A dropped support email is invisible. You find out from the refund request.
An AI that answers your customers wrongly is a support ticket that scales.
A chat widget is an unauthenticated write endpoint pointed at your phone. Guess who finds it first.
last reviewed 2026-08-04 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice