I build chatbots as interfaces to a process, not collections of buttons tied to one messenger. Telegram, MAX, and VK differ in authentication, message formats, button constraints, payments, and publishing rules. Applications, statuses, permissions, and reminders stay in shared business logic, while each channel connects through an adapter.

The first question is what the bot changes in real work: capture a structured request, show a CRM status, send an alert, take payment, or open a mini app. Every flow defines its state, data source, repeated-delivery behaviour, and handoff to a person. Duplicate messages must not duplicate operations; an unavailable CRM must produce a useful user status and an operator log.

n8n works well for simple flows such as receiving a webhook, transforming a few fields, sending a message, and recording the result. Complex permissions, long-lived state, queues, calculations, and domain rules are safer in tested code with its own data model.

The scope is the bot, its server-side logic, and agreed integrations. Support content, operator staffing, and third-party licences remain with the process owner. Acceptance covers new and returning test users, repeated commands, unavailable APIs, state recovery, and denied roles. A broadcast-only channel usually needs no custom bot.