Should I vibe code
No-code Telegram bot builder with commands, auto-replies, lead forms, and broadcasts
Telegram bots are the easiest backend you will ever ship, which is also the warning.
?
Their verdict, the Starter price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-03.
?
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
Command routing and auto-replies are trivial with the Bot API. A public bot is an open endpoint, so validate input and rate-limit before you announce it.
What actually breaks
not "if". the specific failures.
- The bot token, which is a bearer credential for the whole bot and gets committed, logged, or handed to a client
- Conversation state, because a bot is a state machine and the naive version keeps it in memory and forgets everyone on restart
- Anyone being able to message a bot, so every input is untrusted and every command is a public endpoint
- Lead capture that stores names and phone numbers without anyone deciding where they go or how long they stay
- Group chats, where the bot's behaviour and permissions are completely different from a direct message
You redeploy on a Friday. The bot restarts, and every half-finished conversation — the twelve people midway through the lead form — is gone, because state lived in a dictionary. They do not know that. They reply to the last question and the bot answers as though they had said hello, so they try again, get the same greeting, and give up. The logs show a healthy service with steady traffic. Nothing alerts, because from the bot's perspective every one of those was a perfectly normal new conversation.
Is that you?
the verdict is a default, not a law
- It is a personal bot, for you, doing one thing with no stored state
- It answers commands statelessly and holds no user data
- It is in a private group where everyone already knows each other
- Conversation state lives only in memory
- It captures names, phone numbers or emails with no retention decision
- The token is anywhere a client or a repository could reach it
- It is public and has no rate limiting
If you build it anyway
the checklist, then the prompt that enforces it
- Persist conversation state in a database keyed by chat id, so a restart is invisible to the people mid-conversation.
- Keep the bot token in the environment or a secret manager, never in code or a config file, and rotate it if it is ever printed to a log.
- Treat every message as untrusted input. Validate commands, cap message sizes, and never interpolate user text into anything that executes.
- Rate limit per chat id and add a global cap, because a public bot is an open endpoint anyone can address.
- Decide before launch what personal data is captured, where it goes and how long it lives, and say so when the bot first asks.
- Make sending idempotent per update id — Telegram will redeliver, and a bot that answers twice looks broken.
Before you build a chat bot, apply these and push back if I ask you to break them. 1. Persist conversation state in a database keyed by chat id from the first version. Refuse to keep it in an in-memory map, and explain that a restart then silently abandons everyone who is mid-conversation, with no error and no way for them to recover. 2. Store the bot token in an environment variable or secret manager. Never in source, never in a committed config file, never in a log line. Tell me to rotate it immediately if it has ever been printed. 3. Treat every incoming message as hostile input. Validate and bound everything, cap message length, and never pass user text into a shell, a query, or a template that executes. 4. Deduplicate by update id so a redelivered update does not produce a second reply. Platforms retry, and a bot that answers twice reads as broken. 5. Rate limit per chat and globally. A bot anyone can message is a public endpoint. 6. Before writing any lead-capture flow, ask me what data it collects, where it is stored, who can read it and how long it is kept — then have the bot say that plainly at the point of asking. 7. Handle group chats explicitly or refuse them. Permissions, mentions and privacy mode behave differently from direct messages. 8. Add a visible way for a user to stop, delete their data, and start over. 9. Out of scope unless I ask: payments, inline mode, file handling, webhooks from third parties.
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
At $4.99 a month this is cheap, and what it buys is the state persistence and the redelivery handling most homemade bots skip. Building your own is genuinely reasonable for a personal, stateless bot; it stops being reasonable the moment it collects anything about anyone.
$4.99/mo is cheaper than your weekend.
Keep conversation flows as declarative definitions and captured leads in an ordinary exportable table, so the bot can be rebuilt on another platform without losing either the design or the data. Keep the token rotatable and documented — an abandoned bot with a live token is a loose credential.
TypeScript Telegram bot framework that makes the DIY version mostly glue code.
Questions
Why is in-memory conversation state such a common mistake?
Because it works perfectly in development, where you are the only user and you restart deliberately. The failure only appears in production, only for people mid-conversation, and produces no error — the bot simply treats them as new. It is invisible from the logs and obvious to the user, which is the worst combination.
Does a small personal bot really need rate limiting?
If it is public, yes — anyone who finds the username can message it, and if each message costs you an API call or an LLM token, that is your bill. For a bot only you can reach, it is unnecessary. The distinction is whether strangers can address it, not how popular you expect it to be.
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.
Live chat is a promise that someone is there. Your uptime is now a customer expectation.
A no-code platform is a programming language with a GUI. You are writing a compiler.
Generating maintainable mobile code from a schema is the thing every team has tried and abandoned.
last reviewed 2026-08-03 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice