Модульный конструктор для дел: собираем свою систему и подключаемся к любой форме организации

Календарь, задачи, заметки, почта. Мы используем десятки инструментов, но они не умеют жить вместе. Данные размазаны по сервисам. Команда в Битрикс24, семья в WhatsApp, клуб в Google Calendar. Везде свой интерфейс, свои правила, своя изоляция.

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

MVP собрано и проходит тестирование. Дальше — рассказ о том, что получилось, и приглашение к обсуждению архитектуры.

Проблема

Рабочий день начинается с того, что я открываю пять приложений. Заметки в Obsidian. Задачи в Todoist. Почта в Spark. Календарь в Google Calendar. Командная вики в Notion.

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

С командой хуже. Чтобы дать доступ к общему календарю, нужно чтобы все зарегистрировались в Google. Чтобы общий список задач — зарегистрировались в Notion. Чтобы чат — в Telegram. Каждый раз: аккаунт, настройки, приглашения, права. Данные команды живут на чужих серверах и под чужими правилами.

Малый бизнес и команды часто сидят на Битрикс24. Это комбайн: CRM, задачи, чат, календарь, диск, телефония — всё в одном. Для отдела продаж на 15 человек — рабочая лошадка. Пока не нужно выйти за пределы экосистемы.

Проблема начинается, когда личное не лезет в Битрикс24. Идея для pet-проекта, семейный список покупок, план ремонта — это не «сделка» и не «задача по CRM». Тащить такое в рабочий контур не хочется. Данные перемешиваются. Уведомления о домашних делах приходят вперемешку с входящими от клиентов. Интерфейс, спроектированный для воронок продаж и канбанов, становится препятствием, а не помощью.

Есть «Яндекс 360 для бизнеса» — почта, диск, календарь, мессенджер. Корпоративный мини-Google. Хорош для почты и файлов. Но модуль задач — это просто списки. Без зависимостей, без проектного трекинга, без связи с календарём в том смысле, в каком это нужно команде разработки или дизайн-бюро.

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

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

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

Идея

Представьте: одно приложение. Вы запускаете его и выбираете модули, которые нужны. Только календарь и задачи. Или календарь, задачи, заметки и почта. Ничего лишнего.

Теперь вы хотите общий календарь для семьи. Вы запускаете это же приложение на домашнем сервере (или просто на своём компьютере) в режиме ноды. Нода — это организационный узел. Семейная нода содержит общий календарь, список покупок, важные контакты. Вы приглашаете жену, мужа, бабушку. Каждый получает доступ ровно к тому, что ему нужно. Бабушка видит только календарь. Ребёнок — список домашних дел.

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

Одно приложение. Два режима. Данные там, где вы решаете.

В отличие от Битрикс24 или Мегаплана, нода не навязывает структуру. Нода — это просто контейнер для модулей и прав. Хотите — запустили CRM-модуль и строите воронку продаж. Хотите — только календарь и список покупок. Никаких обязательных «сделок», «контактов», «компаний». Никакой предустановленной бизнес-логики. Пространство под ваши сценарии.

Как это работает

В основе архитектуры — три слоя.

Слой 1: Личный узел

Приложение на компьютере пользователя. Electron + React для интерфейса, Rust-ядро под капотом. Модули — это изолированные движки: движок заметок, движок календаря, движок задач. Они общаются через общую шину событий.

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

Данные хранятся локально в SQLite. Приложение работает оффлайн. Все изменения сначала сохраняются у пользователя.

Слой 2: Организационная нода

То же приложение, запущенное с флагом --mode node. Может работать без графического интерфейса — как фоновая служба. Содержит общие данные: семейный календарь, рабочие задачи, вики отдела.

Нода управляет правами. Вот конфигурация семейной ноды:

node:  type: family  name: "Семья Ивановых"  port: 9090modules:  - calendar:      shared: true      name: "Семейный календарь"  - tasks:      shared: true      name: "Список покупок"      lists:        - "Продукты"        - "Домашние дела"members:  - id: alice    role: admin    modules: [calendar, tasks]  - id: bob    role: member    modules: [calendar, tasks]  - id: grandma    role: viewer    modules: [calendar]

Права проверяются на каждое действие. Бабушка не может удалить событие. Ребёнок не может изменить состав семьи. Нода ведёт аудит-лог: кто что сделал и когда.

Слой 3: Синхронизация

Личные узлы общаются с нодой по защищённому каналу. Протокол простой: push/pull.

Пользователь создал задачу → изменение ушло на ноду. Нода приняла, проверила права, сохранила, разослала остальным участникам. Если участник был оффлайн — он получит изменения при reconnect.

Синхронизация работает по принципу «звезда»: все общаются через ноду. Не P2P между участниками напрямую. Почему:

• Нода всегда онлайн (или доступна, когда нужна синхронизация)

• Нода — единый источник прав

• Нода хранит полную историю изменений и делает бэкапы

• Для семьи из 5 человек или команды из 20 задержка «звезды» незаметна

Данные шифруются в покое и при передаче. Ключи хранятся на ноде и выдаются только авторизованным участникам.

Модули и их двойная природа

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

В интерфейсе календаря Алиса видит:

• Свои личные события (йога в 8:00, визит к врачу)

• События семейной ноды (день рождения мамы, субботний ужин)

• События рабочей ноды (стендап в 10:00, дедлайн проекта)

Всё в одном окне, но с цветовым разделением: синий — личное, зелёный — семья, оранжевый — работа. Данные не смешиваются. Семейный сервер не видит рабочих событий. Рабочий сервер не видит семейных.

Один интерфейс. Чёткие границы.

AI-агент с доступом ко всем модулям

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

Что это даёт: AI может действовать кросс-модульно. «Найди заметки про проект X, проверь календарь на следующую неделю и предложи слоты для созвона». «Прочитай вчерашние письма от клиента, создай задачи по каждому поручению и поставь дедлайны в календарь».

Такого нет ни в Битрикс24 с его CoPilot (он заточен под CRM-сценарии), ни в Яндекс 360 (там AI — это расшифровка звонков и суммаризация писем). Здесь у агента сквозной доступ ко всем данным, включая личные заметки и семейный календарь.

Стек

• Rust-ядро: tokio, rusqlite, tonic (gRPC), serde. Управление модулями, шина событий, сетевая подсистема, синхронизация.

• Electron + React: оболочка, система UI-слотов, виджеты модулей.

• Python (AI sidecar): FastAPI + локальные модели или API OpenAI. Семантический поиск, NLP-команды, умные предложения.

Один репозиторий. Один бинарник на выходе. Флаг --mode определяет поведение.

Сравнение с существующими решениями

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

Что собрано на сейчас

MVP проходит внутреннее тестирование. На этом этапе работает:

• Локальное ядро с EventBus и регистрацией модулей

• Модули Заметок и Задач (создание, редактирование, поиск)

• Запуск приложения в режиме ноды (headless)

• Протокол синхронизации push/pull между личным узлом и нодой

• Базовая система прав (роли admin, member, viewer)

• Приглашения по коду доступа

В ближайших спринтах:

• Модуль Календаря с синхронизацией

• AI-агент с доступом к модулям

• Шифрование данных на ноде

• Веб-админка для управления нодой

Открытые вопросы — и здесь нужно мнение сообщества

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

1. Протокол синхронизации

Сейчас у нас простая pull/push-модель через gRPC. Этого хватает для небольших групп. Но что делать с конфликтами при одновременном редактировании? Два варианта:

• CRDT (Conflict-free Replicated Data Types). Автоматическое разрешение конфликтов без арбитра. Плюс: настоящий offline-first, изменения сливаются корректно при любом порядке. Минус: сложность реализации, особенно для календаря (перемещение события — это не вставка символа в текст).

• Last-write-wins с историей. Нода принимает изменения и при конфликте сохраняет более позднее, но хранит историю. Плюс: проще. Минус: возможна потеря данных при реальном конфликте.

Что выбрали бы вы для бизнес-модулей вроде календаря и задач? CRDT или достаточно LWW с возможностью ручного отката?

2. Одна нода или федерация

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

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

Нужна ли федерация? Или независимые ноды — достаточная модель для реальных сценариев?

3. Права доступа: детализация

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

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

Насколько детальной должна быть система прав в минимально жизнеспособной версии? Что критично иметь с первого дня, а что можно отложить?

4. Хранение данных на ноде

Сейчас нода хранит всё в SQLite. Для семьи из пяти человек с календарём и списком покупок — ОК. Для компании из 200 человек с вики, задачами и файлами — нет.

Когда нужна нормальная СУБД? Достаточно ли SQLite с WAL-режимом для первых реальных пользователей? Или сразу закладывать PostgreSQL и S3-совместимое хранилище для файлов?

Зачем это всё

Рынок инструментов продуктивности поделён. Одиночки выбирают между Obsidian, Notion, Todoist. Компании в России — между Битрикс24, Мегапланом, Яндекс 360. Но между «я» и «корпорация» — пустота.

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

Мы хотим закрыть эту дыру. Дать людям инструмент, который:

• Собирается под них, а не наоборот

• Не привязан к чужому облаку

• Позволяет создать общее пространство без регистрации в десяти сервисах

• Работает на их оборудовании — от мощного сервера до Raspberry Pi в кладовке

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

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

P.S. Репозиторий готовим к публикации. Пока можно писать в личку на Хабре или в комментарии — вышлю приглашение в закрытую бету.