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

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

Идея звучит логично. Более того — она почти всегда кажется экономически оправданной на старте. Но на практике это один из самых недооцененных проектов, с которыми мы сталкивались.

Мы — команда, которая разрабатывает платформу корпоративных коммуникаций Frisbee. На рынке мы уже больше 10 лет. За это время не раз видели одну и ту же историю: компания решает «сделать свой чат», закладывает на это несколько месяцев, а через год-два либо пересматривает подход, либо приходит к готовым решениям.

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

Проблема в другом. В большинстве случаев решение «сделать своё» принимается с ожиданиями уровня «это же просто чат». А реализовывать приходится систему уровня полноценной платформы коммуникаций. И вот этот разрыв между ожиданиями и реальностью — как раз то, что чаще всего и ломает проекты. Давайте посмотрим, где он возникает.

Где заканчивается чат и начинается продукт

Если говорить честно, сделать чат — не проблема. Любой опытный разработчик соберет прототип за пару недель. Просто отправка сообщений — это давно не высшая математика.

И вот здесь возникает первая ловушка: кажется, что масштабирование — это просто «добавить еще фич» (как рождаются эти самые фичи, мы подробно писали тут).

На практике в какой-то момент становится очевидно, что корпоративный мессенджер — это уже не чат, а полноценная платформа с сотнями функций, которые должны одинаково эффективно работать на всех видах устройств. Пользователь не воспринимает его как «внутренний инструмент» и ждет ровно того же уровня, к которому привык в публичных продуктах. Чтобы все синхронизировалось, быстро искалось, не ломалось, работало на телефоне и не теряло сообщения.

С этого момента проект перестает быть «задачей для команды разработки» и начинает превращаться в отдельное направление.

Немного про деньги

Самая частая ошибка — недооценка стоимости команды.

Если говорить про минимально жизнеспособную конфигурацию, то это уже не пара разработчиков. Это полноценные функциональные команды (фиче-команды), состоящие из backend-программистов и фронтенд-разработки (веб- и толстые клиенты), мобильная разработка под iOS и Android, бизнес-аналитики, UI/UX-дизайнеры, тестировщики, а также группы инженеров-архитекторов, команды DevOps, DevSecOps, и NetOps, технические писатели, специалисты по информационной безопасности, а также дежурные 24/7 команды технической поддержки и команды мониторинга и эксплуатации.

При этом задачей каждой фиче-команды является разработка одной из функций мессенджера таким образом, чтобы при доставке пользователям она обеспечивала одинаковые пользовательские качества на всех устройствах. Тут и находится самое интересное для бюджетирования — объем функций, количество команд, время, деньги. Привычных функций в мессенджерах несколько сотен. Стоимость одной фиче-команды разработки можно примерно рассчитать на основе данных порталов вакансий. А вот как быстро вы хотите получить продукт, будет зависеть от количества фиче-команд и сроков разработки каждой из сотен функций. Плюс к этому всему еще надо посчитать команду инфраструктуры, команду безопасности, команду эксплуатации.

При чем этот подход одинаков как для сценария, когда вы пытаетесь создать что-то с нуля, так и для сценариев, когда за основу “вашей разработки” вы берете, чьи-то базовые наработки из опенсорса. Разница лишь в том, что во втором случае ваш перечень необходимых пользователям функций будет немного меньше на старте. Поэтому именно на старте такое движение кажется заманчивым, но дьявол скрывается за поворотом, спустя несколько месяцев инвестирования.

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

Сроки при этом — от года до состояния, которое хотя бы минимально можно отдать пользователям. Если компания изначально готова к таким инвестициям — это нормальная история. Но чаще ожидания другие: «соберем MVP за пару месяцев, а дальше как-нибудь». Практика показывает, что «как-нибудь» здесь не случается, и затраты компании на псевдопродукт уже по итогам года значительно превышают стоимость покупки готового полноценного решения.

Где начинается сложность, которую нельзя ускорить

Если же компания идет в сторону собственного продукта, то довольно быстро всплывают вещи, которые невозможно «сделать быстрее за счет усилий».

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

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

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

Особая история — безопасность. Часто именно она становится причиной, по которой компания вообще задумывается о своем решении. Но на практике безопасность — это не фича, а процесс. Аудиты, пентесты, анализ уязвимостей на регулярной основе.

И, конечно, разнообразие клиентов и устройств, на которых должен быть доступен функционал приложения, мобильные клиенты (iOS, Google Android, Huawei), клиент для браузера, приложения для MacOS, Windows, Linux — без них мессенджер в 2026 году просто не воспринимается как корпоративный рабочий инструмент. А значит, синхронная работа команд по каждой функции является постоянной заботой.

Жизнь после релиза: самый недооцененный этап

Есть один момент, который почти всегда упускают на старте. Даже если вы вложили 1 миллиард рублей и сделали какой-то продукт — это не финал. Это только начало.

Потому что дальше начинается активная жизнь системы: пользователи постоянно хотят новые функции, меняются требования, появляются интеграции, шлифовка багов. И команда не может разойтись, потому что продукт начинает жить своей жизнью. У нас в Frisbee релизы выходят регулярно (по сути, каждый месяц), и это нормальный ритм для такого класса продуктов.

Но и это не все. Сегодняшнему искушенному пользователю мало просто насыпать новых фич: ему про них нужно доступно рассказать, показать, научить, то есть запаковать и презентовать. Поэтому наша команда, например, постоянно снимает с разработчиками обучающие и обзорные видео по новым фишкам с привлечением профессионального видеопродакшена, пишет пресс-релизы, делает текстовые инструкции, разжевывая не только как, но и зачем, почему, удобно ли вам. Пользовательские ожидания постоянно растут, и остановиться в развитии здесь просто не получится.

Мы видели несколько кейсов, когда компании убегали в собственную разработку, год-два инвестировали в нее, а потом все равно возвращались к нашим готовым решениям. Не потому что не справились, а потому что поддержка и развитие оказались дороже, чем ожидалось. Причем речь идет не об условных малых и средних бизнесах, а о крупных игроках российского рынка с большим количеством инженеров в штате. Но даже они “обжигались” с такой простой на первый взгляд вещью, как разработка собственного мессенджера. Каждый должен заниматься своим бизнесом. Компании-лидеры в той или иной нише зарабатывают на своих продуктах и услугах, разработка внутреннего продукта для них — всегда затраты. Компании теряли время, инвестиции, тонны ожиданий, отвлекали свои ресурсы от основного бизнеса, но в итоге возвращаются к нам или коллегам по рынку.

Так стоит ли делать свой мессенджер?

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

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

Мы со своей стороны просто делимся тем, как это выглядит изнутри. Без попытки отговорить или, наоборот, убедить. А дальше гораздо интереснее услышать ваш опыт.

В вашей компании есть корпоративный мессенджер? Пробовали ли вы пользоваться собственным решением и что из этого получилось? Сколько сотрудников в вашей компании? Пишите в комментариях, чем пользуетесь и какие функции для вас важны в корпоративных мессенджерах.