Как создать мессенджер: технологии, этапы и стоимость

Первое, что стоит сделать, — понять, в какой вы колонке. От этого зависит всё остальное.

Причина не в моде, а в стечении обстоятельств. Западные корпоративные мессенджеры с российского рынка ушли: обновления и поддержка недоступны, а держать рабочие процессы на сервисе без гарантий — риск. Публичные мессенджеры выглядят бесплатной альтернативой, но не закрывают корпоративные требования: нет управления доступами, нет журналов, история переписки живёт на чужих серверах, а уволившийся сотрудник уносит все чаты в своём личном аккаунте.

Добавляется регуляторная часть: для госкомпаний и объектов критической информационной инфраструктуры нужно решение из реестра отечественного ПО, а данные должны храниться в России. Это резко сужает выбор и объясняет, почему разговор так часто заканчивается на размещении в собственном контуре.

Российский рынок на этот спрос ответил: есть eXpress с более чем миллионом корпоративных пользователей, «Пачка» в реестре отечественного ПО, Roschat, существующий только в варианте on-premise, а также VK Teams и Compass. То есть чистая задача «нужен корпоративный чат» в 2026 году закрывается покупкой, а не разработкой, — и об этом честно стоит сказать до обсуждения бюджета.

Три пути, между которыми стоит выбирать осознанно.

Со стороны мессенджер выглядит просто: список чатов и поле ввода. Внутри — набор механизмов, каждый из которых умеет ломаться по-своему.

Транспорт сообщений. Постоянное соединение между клиентом и сервером (обычно WebSocket) для мгновенной доставки, пока приложение открыто, и push-уведомления, когда оно закрыто. Это две разные дороги для одного сообщения, и обе нужно поддерживать в согласованном состоянии.

Гарантии доставки и статусы. Отправлено, доставлено, прочитано — за каждым статусом стоит подтверждение и обработка повторов. Сообщение, отправленное в метро при пропадающей сети, не должно ни потеряться, ни продублироваться.

История и синхронизация. Один пользователь заходит с телефона, ноутбука и планшета: история, прочитанность и черновики должны совпадать. Это одна из самых недооценённых по трудозатратам частей.

Медиа. Файлы и фото не идут через тот же канал, что текст: нужны отдельное хранилище, превью, докачка при обрыве, ограничения по размеру и сроку хранения.

Групповые чаты и права. Участники, администраторы, приглашения, выход из чата, история для новых участников — что видит человек, добавленный вчера, из переписки за прошлый год.

Всё это живёт на серверной стороне и требует зрелой серверной архитектуры: очереди, кеш, база под большой поток сообщений и мониторинг. Мессенджер — классический пример продукта, где основная сложность не в интерфейсе.

Три реалистичных варианта, и выбор влияет на сроки, безопасность и совместимость.

Тема, где статьи обычно скатываются в лозунги. Разберём по существу.

Транспортное шифрование (TLS) обязательно всегда: он защищает канал от перехвата. Дальше сообщения лежат на сервере в расшифрованном виде или зашифрованными ключом сервера.

Сквозное шифрование (E2EE) означает, что расшифровать сообщение может только получатель: ключи есть у устройств, но не у сервера. Так работают Signal Protocol с алгоритмом двойного храповика и Olm/Megolm в Matrix. Для публичного мессенджера это стандарт де-факто.

А теперь неудобная правда для корпоративного контура: сквозное шифрование прямо противоречит части корпоративных требований. Если сервер не может прочитать сообщения, то невозможны: поиск по всей переписке, выгрузка истории по запросу службы безопасности, DLP-контроль утечек, восстановление чатов уволившегося сотрудника, аудит для комплаенса.

Компании, которые сначала требуют «как в Signal», на этапе согласования с безопасностью часто разворачиваются на обратное.

Рабочий компромисс, который мы обычно и проектируем: транспортное шифрование плюс шифрование хранилища, размещение в контуре компании, строгие права доступа и журналирование, а сквозное шифрование — только для отдельных приватных чатов, где оно осмысленно, и с явным отключением там, где нужен аудит.

Отдельно про границу: криптографию мы не изобретаем — используем проверенные библиотеки и стандартные протоколы. Если проекту нужна аттестация по линии регуляторов, это работа профильных подрядчиков, и мы говорим об этом сразу, а не после подписания договора.

Для мессенджера пуши — не второстепенная функция, а половина продукта: сообщение, о котором пользователь не узнал, не доставлено.

Механика простая на бумаге и капризная на практике. Пока приложение открыто, сообщение приходит по соединению. Когда свёрнуто или закрыто, доставку берут на себя сервисы платформ: APNs у Apple, Firebase Cloud Messaging у Google.

И здесь российская специфика: на части Android-устройств, продающихся в России, нет сервисов Google. Пуши через Firebase на них просто не доходят, а пользователь узнаёт о сообщении, только открыв приложение. Решения два: доставка через RuStore и собственный канал доставки на долгом соединении для устройств без GMS. Оба нужно закладывать в архитектуру и обязательно проверять на реальных устройствах, а не в эмуляторе.

Второй нюанс — агрессивное энергосбережение на прошивках некоторых производителей: система убивает фоновые процессы, и соединение рвётся. Это лечится корректной работой с системными ограничениями и тестами на живых аппаратах.

Подробнее про устройство клиентской части — в материале про архитектуру мобильного приложения. Мы делаем мобильные приложения на Flutter, и в мессенджерах именно доставка сообщений обычно требует нативных вставок.

То, что отличает корпоративный мессенджер от чата и чего не бывает в публичных продуктах.

Каталог пользователей. Сотрудники не регистрируются сами: они приходят из Active Directory, LDAP или кадровой системы вместе с подразделениями и должностями. Принят человек — появился в мессенджере, уволен — доступ закрыт автоматически.

Единый вход. Корпоративный SSO вместо отдельного пароля; для части компаний — обязательная двухфакторная аутентификация.

Права и политики. Кто может создавать общие каналы, кто пишет в объявления, можно ли переписываться с внешними контактами, разрешена ли передача файлов определённых типов.

Журналирование и DLP. Кто что писал и когда, выгрузка истории по запросу, контроль передачи конфиденциальных данных. Без этого мессенджер не пройдёт согласование в крупной компании.

Размещение и данные. Свой контур или российское облако, шифрование хранилища, резервные копии, план восстановления.

Плюс интеграции, которые превращают чат в рабочий инструмент: заявки и согласования из корпоративных систем, уведомления из мониторинга, боты для типовых операций, обмен с производственным контуром.

Мессенджер дороже в эксплуатации, чем обычное приложение с тем же числом пользователей, и это стоит понимать заранее.

Причины три. Первая — долгие соединения: каждый активный клиент держит открытый канал, и сервер считает не запросы в секунду, а одновременные подключения. Вторая — медиа: файлы и фото копятся вечно, и хранилище растёт быстрее, чем ожидают; отсюда политики хранения и очистки. Третья — трафик и география: чем шире распределена компания, тем важнее задержки и расположение серверов.

Практические выводы для сметы: планируйте не только разработку, но и инфраструктуру с администрированием; на старте закладывайте политику хранения истории и файлов; проверяйте поведение под нагрузкой до запуска — мессенджер деградирует не плавно, а резко, когда упирается в лимит соединений.

Соблазн сделать «как в Telegram» губит бюджеты. Реалистичная первая версия закрывает основной сценарий и не более.

В MVP обычно входят: личные и групповые чаты, отправка файлов и изображений, статусы доставки и прочтения, поиск по сообщениям, push-уведомления, интеграция с каталогом сотрудников, веб-клиент и мобильные приложения.

Что откладывают без потери смысла: аудио- и видеозвонки (это отдельная подсистема с медиасервером и своим бюджетом), конференции с записью, треды и реакции, боты и мини-приложения, переводчик, сквозное шифрование для всех чатов. Что именно попадёт в первую версию, определяется гипотезой — тем же способом, что и в любом MVP: сначала то, без чего продукт не работает.

Отдельно про звонки. Их почти всегда просят «сразу», и почти всегда их разумно вынести во вторую фазу: голос и видео требуют медиасервера, работы с качеством связи и отдельного цикла тестирования на реальных сетях.

Разброс огромный, потому что «мессенджер» — это и чат внутри сервиса на несколько экранов, и корпоративная платформа с шифрованием, каталогом и звонками. Смету двигают пять факторов: число платформ (веб, iOS, Android), объём корпоративной обвязки, требования по шифрованию и аудиту, наличие звонков и конференций, ожидаемая нагрузка.

Ориентиры по нашим работам: заказная разработка продукта под ваш процесс начинается от 1,7 млн ₽, мобильные клиенты — от 1,8 млн ₽, интеграция с каталогом пользователей или внешней системой — от 150 тыс. до 1,5 млн ₽ за одну.

Сравнивать это стоит с альтернативой: подписка на готовое решение из реестра для сотни сотрудников обойдётся заметно дешевле разработки, и если ваша задача закрывается готовым продуктом, мы так и скажем. Разработка выигрывает, когда мессенджер связан с процессами или продуктом. Что дешевле именно в вашем случае, видно после разбора — оценка проекта бесплатная: опишите задачу.

Делать «свой Telegram» без ниши. Технически повторить функции можно; конкурировать за пользователей с бесплатным продуктом, в котором уже все их контакты, — нет.

Требовать сквозное шифрование и аудит одновременно. Эти требования противоречат друг другу; решение принимают до разработки, а не в середине проекта.

Забыть про устройства без сервисов Google. Пуши не доходят у части аудитории, а команда об этом не знает, потому что тестировала на своих телефонах.

Начать со звонков. Медиасервер и качество связи — отдельный проект внутри проекта; без работающего текстового ядра он бессмыслен.

Не спроектировать хранение. Файлы копятся, база растёт, через год расходы на инфраструктуру удивляют.

Игнорировать каталог сотрудников. Ручное создание учётных записей означает, что через полгода в мессенджере будут уволившиеся, а новые сотрудники — без доступа.

Три шага до брифа. Первое — определить задачу из трёх: корпоративный контур, чат в продукте или публичный мессенджер. Второе — выяснить требования безопасности: нужен ли реестр, где хранятся данные, требуется ли аудит переписки и DLP; именно они определяют архитектуру. Третье — честно оценить, закрывается ли задача готовым решением: если да, разработка не нужна.

Если после этих трёх шагов остаётся заказная разработка, дальше собирают MVP: основной сценарий, платформы, интеграция с каталогом сотрудников, план по звонкам во второй фазе.