Вопрос на моём сайте сформулирован просто: «Где будет работать бот?» Ответ — на сервере, компьютер заказчика для этого не нужен. Телефон с Telegram можно убрать в карман. Только программу, которая принимает заявки и составляет ответы, в этот карман вместе с телефоном мы не положили.
У бота есть адрес в мессенджере, имя и картинка, а вся переписка помещается рядом с обычными разговорами — от этого легко перейти к мысли, будто программа тоже поселилась внутри Telegram и больше ей ничего не требуется. В официальном FAQ Telegram создание описано иначе: аккаунт регистрируют через BotFather, затем соединяют с серверной частью через API. Аккаунт уже есть, а отвечающую программу ещё нужно запустить. Вот между этими событиями и помещается вопрос о размещении.
Для заказчика я разделяю его на две части. Где программа будет исполняться — техническая. Кто оплачивает это место и кто умеет вернуть работу после остановки — организационная. Купить аренду легче, чем договориться о второй части. Оплаченный сервер сам по себе не сообщает, какой проект на нём установлен и кто получил инструкцию.
На сайте мои условия сформулированы без привязки к одному хостингу. Если сервер у вас есть, можно обсуждать запуск на нём. Если нет, помогу с выбором и настройкой. Аренду вы оплачиваете напрямую хостингу. В калькуляторе подбор и настройка перечислены отдельно; перенос на ваш сервер и инструкция по управлению указаны без доплаты. Это разные строки работы, а не несколько названий одного ежемесячного платежа.
Расходы лучше записать раздельно ещё до заказа. Разработка — программа с согласованными действиями, размещение — место для её работы. Поддержка определяет помощь после запуска, если вы её заказываете; на сайте она вынесена отдельной позицией на месяц. Из стоимости аренды нельзя вывести состав поддержки разработчика, как из покупки стола нельзя вывести обязанность продавца каждый день разбирать бумаги на нём.
Сравнивать тарифы по одной цифре я бы не начинал. Не знаю, какая мощность нужна вашему проекту, пока неизвестно, что он будет делать. Меню с ответами и обработка тяжёлых файлов ставят разные задачи. До покупки полезно описать разработчику сами операции, способ хранения данных и ожидаемое использование. Число подписчиков без этого описания — плохой заменитель требований: оно не объясняет, что именно люди одновременно попросят у программы.
Впрочем, и слово «сервер» ещё не требует отдельного железного ящика под столом. Для выбора места важнее возможность постоянно выполнять нужную программу и хранить её данные, чем фотография оборудования. Если используется уже оплаченная площадка, я советую сначала выяснить, разрешает ли она запуск такого приложения. Наличие сайта на хостинге само по себе этого вопроса не закрывает. Просить купить ещё один тариф до этой проверки незачем.
С доменом похожая история. В документации Bot API есть два взаимоисключающих способа получать события — long polling и webhook. В первом программа сама запрашивает обновления у Telegram; во втором Telegram отправляет их на указанный HTTPS-адрес. Публичный адрес для входящих запросов — требование выбранного способа подключения, а не обязательная покупка для любого бота.
Это не соревнование хорошего способа с плохим. Заказчику достаточно получить от разработчика понятный ответ, какой выбран и что из-за него нужно оплатить или настроить. Если предлагается домен, полезно спросить, для какой части проекта он понадобится — для приёма событий, страницы или другого сервиса рядом с ботом. Объяснение должно относиться к вашему устройству работы, а не к магическому свойству слова «профессиональный».
У двух способов есть общее ограничение — Telegram хранит входящие обновления не дольше 24 часов. Это написано в разделе получения событий. Я бы не принимал эту очередь за запасной журнал заказов. Она помогает передать сообщения программе, но из её существования не следует, что ваша таблица заявок где-нибудь уже сохранена, а обращения будут ждать до возвращения разработчика из долгого отсутствия.
Сутки — не архив.
Поэтому перед запуском стоит отдельно спросить о данных. Где лежат принятые обращения, что останется после перезапуска программы, какие копии предусмотрены и как восстанавливать работу. Это вопросы к будущей установке, а не перечисление включённых по умолчанию услуг. Условие о резервной копии имеет смысл, когда известно, что в неё попало и кто умеет ею воспользоваться. Одного успокаивающего названия папки недостаточно.
Сам перезапуск тоже полезно включить в приёмку размещения. Предлагаю согласовать безопасную проверку на тестовых данных: приложение остановили, снова запустили, оно отвечает, ранее сохранённое доступно там, где было обещано. Такая проверка не доказывает бессбойность навсегда. Зато она отвечает на небольшой, но предметный вопрос о том, переживёт ли сделанная установка обычную остановку. Выполнять её на рабочем проекте без согласования я не предлагаю.
За инструкцией начинается ответственность. В ней полезно найти не абстрактное «следить за сервером», а место оплаты аренды, способ связаться с тем, кто обслуживает программу, и понятные действия при остановке. По моим условиям код остаётся заказчику, бот работает под его токеном, доработку можно поручить другому программисту. Чтобы этим правом было удобно воспользоваться, переданные файлы и сведения о размещении нужно уметь найти, а не только помнить, что их когда-то прислали.
Необязательно разбираться в настройках самому. Обязательно понимать хотя бы границу между приложением, арендой и договорённостью о помощи. На странице заказа задачу можно описать обычными словами; вопрос о существующем сервере лучше добавить туда же. Тогда выбор площадки начнётся с того, что уже есть у владельца, а не с очередной покупки на всякий случай.
А компьютер дома можно выключить. При согласованном размещении на отдельном сервере его кнопка питания к вашему боту отношения не имеет.