Куда движется проект
Книга подходит к концу. Семь глав описывали, что проект делает и почему. В последней главе — что будет (без громких обещаний), что может не получиться (без сглаживания), и когда инструмент однозначно не для вас (потому что универсальное решение не бывает действительно универсальным).
Видимый горизонт — следующие двенадцать месяцев
В ближайший год работа сосредоточена вокруг трёх направлений.
Первое — доведение пилотов до production. Ремесленный кооператив рассматривается как кандидат на первый платный пилот; завершение странового режима Belarus — задача мая 2026 года. Образовательная экосистема — задача третьего квартала 2026 года. Зонтик проектов — переход с adjacent сервиса на основной движок — задача второй половины 2026 года. Эти три пилота должны дать первый набор реальных данных о том, как платформа ведёт себя в работе у разных типов организаций.
Второе — интеграция с регуляторным окном. С осени 2026 года в России формируется регуляторное окно вокруг «домовых чатов» в мессенджере MAX. Точные формулировки и сроки нужно сверять с первоисточниками законодательства. Это создаёт ситуацию, в которой governance-функционал, отсутствующий в самих чатах, может быть полезным дополнением. Бот и мини-приложение в MAX, подключённые к движку ComUnify, могут стать подготовительной инфраструктурой вокруг общих собраний собственников жилья: повестка, обсуждение, документы, напоминания. Само юридическое голосование на ОСС проводится по установленному законом каналу, не через нашу платформу.
Третье — закрытие архитектурного долга. Несколько модулей сейчас работают через общий механизм (generic mutation в GraphQL), а не через типизированные резолверы. Это не блокер для production-использования, но создаёт неудобство для разработчиков сторонних клиентов. Работа по типизации идёт постепенно. Параллельно — интеграция с внешними платёжными провайдерами и завершение модуля Accounting (внутренний учёт оплат за курсы и события уже работает в составе Payments, см. таблицу в седьмой главе).
Дальше — без обещаний
За пределами двенадцати месяцев — слишком много неизвестных, чтобы строить детальный план. Технологии меняются, законодательство меняется, рынок меняется. Книга не пытается обещать определённое будущее.
Видимое направление — расширение в смежных юрисдикциях стран, где правовая база похожа на российскую и белорусскую (Казахстан, Армения, страны со схожей кооперативной традицией). Это не обещание выхода — это направление, в котором проект будет смотреть, когда позволят ресурсы.
Видимое расширение продукта — превращение движка в API, на котором сторонние разработчики могут строить свои интерфейсы поверх. Это аналогия со Stripe для платежей: не каждый сайт делает свою платёжную систему, большинство пользуется готовой через API. То же могло бы случиться с governance-функционалом сообществ. Это гипотеза, не подтверждённая текущей выручкой, и потому не входит в обещания раунда — только в долгий горизонт.
На странице «Зачем» подчёркивается: «Мы пишем код под живые группы людей, а не под воображаемый рынок». Это правило остаётся в силе. Большой горизонт — это контекст, в котором делается каждый небольшой шаг. Не цель сама по себе.
Что может не получиться
Открыто проговариваются три класса рисков, по которым проект может не дойти до того состояния, в котором он замышлен.
Риск конкурента с лучшей дистрибуцией. Если крупный игрок (банк, телеком, государственная структура) выкатит конструктор для сообществ с встроенной дистрибуцией на миллионы людей — он отъест большую часть рынка быстрее, чем ComUnify успеет добраться туда же. Защита здесь — не масштаб, а специфика: ComUnify собран как открытая платформа, не привязанная к одному провайдеру. Это создаёт нишу для тех, кто не хочет зависеть от корпоративной инфраструктуры, но не гарантирует выживания при появлении массового конкурента.
Риск регуляторного сдвига. Часть текущих расчётов опирается на ФЗ-493 и сопутствующие нормативы. Если эти законы будут отложены, отменены или изменены — wedge timing-окно закроется или сдвинется, и проекту придётся перестраивать стратегию подключения. Это не катастрофа, но потеря темпа.
Риск исполнительский. Проект сейчас держится на одном архитекторе с подрядчиками. Это модель, которая работает на стадии разработки, но не масштабируется на стадии активных продаж и поддержки многих клиентов. Если до конца 2026 года в команде не появится бизнес-партнёр, способный взять на себя эти функции, темп развития замедлится независимо от качества технического продукта.
Эти риски не означают, что проект обязательно их встретит. Они означают, что проект может их встретить, и в этом случае часть планов придётся пересмотреть. Книга про это говорит, потому что скрывать риски от читателя — плохая позиция.
Когда ComUnify не для вас
Универсальная платформа на самом деле не универсальна. Есть случаи, в которых ComUnify не подходит, и сообщество получит больше пользы от альтернативного решения.
Если вашему сообществу нужна узкая специализированная функциональность. Образовательная платформа, у которой главная задача — массовая дистрибуция курсов с системой реферального маркетинга, — специализированная LMS закроет её лучше, чем модуль Learning поверх общей платформы. Компания со сложным workflow и жёсткой иерархией — корпоративная BPM-система закроет её лучше, чем модуль Workflow на ComUnify. Универсальный движок — это компромисс, и в задачах с одной доминирующей функцией компромисс проигрывает специализации.
Если ваше сообщество устроено иерархически. ComUnify рассчитан на сообщества, в которых решения принимаются коллегиально или с участием членов. Если в вашей организации одно лицо принимает все решения, а остальные исполняют, — корпоративная CRM или BPM подойдёт лучше. ComUnify в такой ситуации добавит сложности без пользы.
Если вам не нужна история. Event Sourcing с time-travel — мощная вещь, но она имеет цену в сложности и производительности. Если вам нужно просто хранить текущее состояние и быстро его обновлять, обычная база данных проще. ComUnify окупается на сообществах, которые живут годами и требуют разрешения споров на основе фактической истории, не на разовых проектах.
Если ваше сообщество уже работает на чём-то и не имеет проблем. Не нужно мигрировать ради миграции. Если у вас Notion, Excel и WhatsApp-чат, и всё работает, и проблем нет — не трогайте. ComUnify имеет смысл, когда существующая инфраструктура начинает мешать, а не когда «можно ещё что-то добавить».
Если что-то из этого вам близко
После восьми глав осталось одно простое предложение. Если задача, описанная в книге, напоминает задачу вашего сообщества — напишите. Покажем что собрали, объясним где обрывы, и скажем, дешевле ли это сделать на нашем движке или собирать своё.
Иногда ответ — «делайте своё». Это нормальный ответ. Мы за то, чтобы хороших инструментов для сообществ было больше, а не за то, чтобы каждое сообщество использовало именно ComUnify.
Оставьте сообщение через форму обратной связи на главной странице. Demo доступен прямо сейчас на dev.comunify.ru — без регистрации компании, без оплаты.
На этом книга заканчивается. Спасибо за внимание.