Тетрадка председателя
Я стал обладателем загородного дома в коттеджном поселке и быстро столкнулся с реальностью, которую многие жители СНТ и поселков считают нормой: платежи, документы, заявки, новости и решения живут в чатах, Excel-файлах и тетрадке председателя.
Тетрадка председателя оказалась святыней, в которой был собран альманах всех взносов и расчетов, именно в нее председатель занес первый оплаченный мной взнос собственника земельного участка.
Дальше были только вопросы:
Где посмотреть начисления? Надо поискать в чате. Кому оплатить? Председатель скинет реквизиты. Где протокол собрания? Кажется, был PDF пару месяцев назад. Кто должник, кто голосовал, кто отправлял заявку? “Как-нибудь ведем”.
Важная оговорка: я не разработчик. Я работаю в IT, занимаюсь операционным менеджментом, раньше был бизнес/системным аналитиком. Поэтому слова вроде API, база данных, миграции, роли пользователей, интеграции и критерии приемки мне были знакомы.
Но знакомы они были скорее теоретически. Одно дело - обсуждать архитектуру на встрече, описывать процессы или писать требования для команды. И совсем другое - самому поднять сервер, подключиться по SSH, разобраться с Docker, понять, почему миграция не применилась, почему приложение работает локально, но падает на VPS, и почему push-уведомления не приходят.
Сначала я посмотрел на поселковый хаос с уверенностью: сейчас быстро навайбкодим портал, наведем порядок, и все заработает.
localhost:3000
Первый локальный прототип действительно дал сильное ощущение прогресса. На localhost появились жители, участки, начисления, новости, документы и чат. Открываешь дашборд, кликаешь по платежам, видишь интерфейс - и мозг радостно говорит: “Ну все, продукт почти готов”.
Разумеется, это была иллюзия. Как оказалось, на локалхосте далеко не уедешь.
Дальше понеслось: виртуальные машины, SSH, Git, Docker Compose, Traefik, домены, HTTPS, переменные окружения, Prisma-миграции, пересборка контейнеров, логи и rollback. Вайбкодинг из игрушки начал превращаться в инженерный процесс.
Codex хорошо помогал писать код, но продукт все чаще упирался не в код. Он упирался в то, как этот код доставить до сервера, как не сломать данные, как не потерять секреты, как понять, что сервис жив, и как откатиться, если что-то пошло не так.
Простая задача “сделаем экран платежей” часто приводила к непредсказуемому результату: Codex мог нарисовать свой дизайн, переставить пользовательский путь или сделать технически правильно, но продуктово не туда.
Как я выстроил свой процесс
На первых порах я работал с Codex максимально просто: писал задачу в окошко. “Сделай страницу платежей”. “Добавь документы”. “Почини чат”. Пока проект был маленьким, это работало почти магически.
Потом пришла классика AI-разработки: контекст. Сессия оборвалась, история потерялась, Codex “обнулился” и уже не помнит, почему мы приняли такое решение, где лежит важная команда, как устроен деплой и почему нельзя трогать конкретный файл.
Так в проекте появились документы не только для людей, но и для агента: AGENTS.md, infra runbook, release checklist, ADR. Obsidian я использовал как удобный локальный навигатор по заметкам, но главные опорные документы: Markdown-документы в репозитории.
Особенно важным стал infra runbook. Раньше деплой был полностью ручным: я коммитил изменения, пушил в Git, подключался по SSH к серверу, подтягивал код, пересобирал контейнеры и смотрел логи. Какое-то время это казалось нормальным: ну а что, работает же.
Потом в какой-то момент все упало. Codex помогал читать логи и разбираться, а потом довольно спокойно объяснил, что я сам создал проблему: неаккуратно закоммитил, смешал runtime-изменения с кодовыми и поехал деплоить поверх грязного состояния.
Я спросил почти в шутку: “А ты сам можешь это делать аккуратнее?” Ответ был примерно: “Не вопрос".
Я был удивлен, но для начала по классике решил сначала зафиксировать правила. Так появился infra runbook: где лежит проект на сервере, какие есть домены, какие сервисы в Docker Compose, как делать web-only deploy, как делать API deploy с миграциями, как смотреть логи, что нельзя коммитить и какие значения считаются секретами.
После этого Codex перестал быть просто помощником, который пишет куски кода. Он стал участником операционного процесса: читает infra runbook, проверяет git status, готовит изменения, обновляет репозиторий, подключается к серверу, пересобирает нужные контейнеры и смотрит логи.
Парадоксально, но пользы стало больше не когда я дал Codex больше свободы, а когда у него появились хорошие ограничения.
Сложные интерфейсы и прототипирование пользовательского пути
Интересная история произошла с интерфейсами. Простая задача “давай добавим статус на экран платежей” часто приводила к непредсказуемому результату: Codex мог нарисовать свой дизайн, переставить пользовательский путь или сделать технически правильно, но продуктово не туда.
Бустом стал Figma Make. Я начал быстро собирать там прототипы экранов: как должен выглядеть чат, как председатель видит начисления, как житель открывает счет, где находится кнопка оплаты, что показывать в пустом состоянии.
Дальше через MCP этот визуальный контекст попадал в Codex. Задача менялась с “придумай экран” на “реализуй вот этот экран в существующем приложении, сохрани API-контракты и паттерны проекта”.
Вайбкодинг стал выдавать более предсказуемый результат. AI хорошо реализует, но продуктовую интонацию и пользовательский путь нужно фиксировать отдельно, что бы потом не приходилось переделывать и жечь тонну токенов.
App-store и Google Play кладут на лопатки
Еще одна иллюзия быстро рассыпалась: “сначала сделаем нормальную веб-версию, а мобильную адаптацию потом”. В 2026 году для такого продукта десктоп - не основной сценарий.
Житель поселка не будет специально открывать ноутбук, чтобы посмотреть начисление или написать председателю. Он стоит у калитки, читает чат с телефона, оплачивает счет из банковского приложения и ожидает, что все будет работать как обычное мобильное приложение.
Сначала я пошел по пути PWA. Один frontend, установка на экран, web push, минимум отдельной мобильной разработки. На практике PWA закрыла часть задач, но за это пришлось заплатить временем и нервами.
Самыми болезненными оказались чаты. Открывается клавиатура, меняется viewport, composer уезжает, список сообщений дергается, скролл живет своей жизнью. Вроде мелочи, но именно они превращают “почти работает” в “пользоваться неприятно”.
Стало ясно: если люди должны пользоваться этим каждый день с телефона, нужны нативные клиенты. Так появились Android на Kotlin + Jetpack Compose и iOS на SwiftUI.
Нативные приложения добавили сложности, потому что теперь любое изменение нужно держать в голове сразу на web/PWA, Android и iOS. Зато появились нормальная работа с клавиатурой, системные push-уведомления, привычная навигация и ощущение приложения, а не сайта, который притворяется приложением.
Но у нативной разработки оказался свой нетехнический Гига-босс: аккаунты разработчиков. В 2026 году мало написать код. Нужно получить валидные оплаченные аккаунты, пройти проверки, закрытое тестирование, подготовить всю полиграфию и описание, настроить подписи, версии, bundle/package id, TestFlight, Google Play и policy pages. Из РФ это отдельный квест.
Честно, я чуть не сломался, у меня ушло около 1,5 месяцев. Но результат радует, на данный момент приложения доступны в обоих сторах.
Что сейчас умеет приложение
На текущем этапе это уже не просто прототип “личного кабинета”. Скорее, это попытка собрать в одном месте повседневную операционку поселка: деньги, коммуникацию, решения и информацию, которая обычно размазана по чатам.
Главная страница работает как короткая сводка для жителя. Здесь видно состояние по участку: баланс, начисления, неоплаченные счета, важные документы и быстрые переходы к основным действиям. Идея простая: человек открывает приложение не “погулять по меню”, а быстро понять, есть ли что-то важное.
На главной также есть погода. Сначала это кажется мелочью, но для загородного поселка погода — вполне прикладная информация: дорога, работы на участке, отключения, снег, ветер, поездка за город. Погода подтягивается по координатам поселка и становится частью ежедневного сценария, а не декоративным виджетом.
Финансовый блок — один из центральных. В системе есть разные типы начислений: регулярные взносы, целевые сборы, разовые платежи, членские взносы, коммунальные компенсации и услуги. Председатель может создавать начисления, а житель — видеть свои счета и оплачивать их через СБП. Для платежей предусмотрены интеграции с T-Bank и YooKassa, а также ручные подтверждения, когда деньги пришли не через автоматический сценарий.
Отдельно есть учет баланса СНТ: поступления, расходы, вложения к расходам и видимость финансовой информации для жителей. Для председателя это инструмент контроля, для жителей — способ снизить вечный вопрос “куда ушли деньги”.
Новости сделаны как общий информационный поток поселка. Можно публиковать объявления, события, важные сообщения, добавлять медиа, собирать реакции и комментарии. Для более быстрых форматов есть stories — короткие публикации, которые живут ограниченное время и хорошо подходят для оперативных сообщений.
Голосования и собрания вынесены в отдельный управляемый сценарий. Председатель может создать собрание, открыть голосование, задать варианты ответа. Житель видит активные голосования, голосует в приложении и понимает, что его голос учтен. Часть голосований также попадает в новостную ленту, чтобы важные решения не терялись в отдельном разделе.
Мессенджер стал отдельной большой частью продукта. Есть общий чат, тематические топики и личные сообщения. В личных чатах можно общаться напрямую с председателем или соседями, а топики помогают не смешивать все в одну бесконечную ленту: отдельно обсуждения, заявки, вопросы по платежам, бытовые темы.
В чатах есть не только текст. Поддерживаются изображения, голосовые сообщения, видео-заметки, ответы на сообщения, редактирование, удаление, реакции, отметки прочтения, статусы присутствия, аватары и push-уведомления. Именно чат оказался одним из самых сложных мест, потому что люди ожидают от него поведения уровня привычных мессенджеров.
Кроме этого, в приложении есть документы, профиль, push-настройки, заявки/инциденты, карта объектов поселка, управление жителями и участками, сервисные счетчики и задел под smart home через Tuya. Не все эти модули одинаково зрелые, но направление уже видно: не заменить один чат другим, а собрать цифровой контур поселка вокруг реальных ежедневных процессов.
Самобичевание. Экзисциональный кризис. Когда задача не равна пользе
С каждой технической и бюрократической заминкой руки буквально опускались. Сначала кажется, что надо просто разобраться с деплоем. Потом - с DNS и HTTPS. Потом - с миграциями. Потом - с PWA. Потом - с Android. Потом - с iOS. Потом - со сторами.
Каждая новая стена выглядела как последняя перед “ну теперь-то все”. Но за ней почти всегда находилась следующая.
Но самый неприятный удар оказался не техническим.
В какой-то момент я показал прототип нескольким председателям и людям из около-коттеджной тусовки. Продукт уже выглядел не как картинка из презентации: были экраны, логика, платежи, документы, чаты, мобильные сценарии. Мне казалось, что сейчас люди увидят это и скажут: “Да, вот оно, нам нужно”.
Они сказали: “Прикольно”.
И все.
Никто не побежал платить. Никто не сказал: “Куда переводить?” Никто не начал срочно внедрять это у себя в поселке. Реакция была доброжелательной, но холодной с точки зрения рынка: интересно, симпатично, но не настолько больно, чтобы достать деньги.
Для меня это было очень болезненно. Я по-человечески расстроился и почувствовал себя беспомощным. Я понял, что могу собрать экран, поднять сервер, подключить платежи, разобраться с push-уведомлениями, я понял, что реализовался как квалифицированный наемный сотрудник и классно справляюсь с поставленными задачами ....... но я не знаю, как продавать этот продукт.
А дальше мозг быстро докручивает до самого неприятного вывода: если за это никто не готов платить, значит, может быть, никому это не нужно. А если никому это не нужно, то вся деятельность - напрасный труд.
Мне понадобилось время, чтобы выйти из этого состояния.
Потом я начал формулировать для себя новую мысль: в найме тебя оценивает система, а на рынке - покупатель и это разные не подлежащие сравнению вещи.
В найме есть понятная рамка: есть задача, есть ее результат. Сделал задачу - молодец. Закрыл тикет - молодец. Починил баг - молодец. Даже если результат не повлиял на бизнес напрямую, внутри системы ты получил подтверждение: работа выполнена.
На рынке такой рамки нет. Здесь неважно, сколько ты старался, сколько ночей разбирался с деплоем и насколько красивый у тебя интерфейс. Важно, готов ли человек или организация отдать деньги за решение своей проблемы.
Ты становишься молодцом только тогда, когда решение действительно полезно людям. А еще честнее - когда кто-то готов за это платить.
Проект изменил мой взгляд на задачи. Раньше задача часто была объектом исполнения: понятно описали, сделали, приняли. Сейчас я все чаще спрашиваю: какую боль это закрывает, кто за это будет благодарен, приблизит ли это продукт к использованию, оплате, доверию или рекомендации?
Фича может быть логичной, красивой и технически интересной. Но для продукта, конечного пользователя и продаж она может не иметь никакого значения.
Сейчас я уже в порядке и смотрю на это спокойнее. Равнодушное “прикольно” - это не приговор, а обратная связь. Значит, нужно лучше понимать сегмент, боль, момент покупки, канал продаж, цену, доверие, возражения и реальный процесс принятия решения в поселках.
Мне удалось найти поддержку у председателя своего СНТ, и мы готовим пилотный запуск. Это уже не абстрактное “кому-нибудь пригодится”, а конкретный сценарий с реальными людьми, платежами, документами и обратной связью.
Параллельно я готовлю материалы, чтобы идти в соседний коттеджный поселок. И здесь начинается следующий слой вопросов, который вообще не похож на разработку.
Как это тарифицировать: брать плату с СНТ, с количества участков, с активных жителей, за модули, за подключение, за сопровождение? Делать дешевый пилот или сразу нормальную коммерческую цену? Как объяснить ценность председателю, который привык решать все через чат, и жителям, которые не всегда хотят еще одно приложение?
Дальше юридический слой: какой нужен договор, нужна ли публичная оферта, как описывать обработку персональных данных, кто оператор данных, где границы ответственности, как оформлять платежи и поддержку.
Потом организационный: на что все это оформлять? Самозанятый, ИП, ООО? Если думать про B2B, договоры с СНТ и потенциальные гранты, возможно, ООО выглядит логичнее. Если идти маленькими пилотами, может быть, сначала достаточно более простой формы. Но это уже отдельная область решений, где “написать код” вообще не помогает.
Где-то рядом появляются вопросы товарного знака, домена, бренда, бухгалтерии, поддержки пользователей, регламентов, коммерческих предложений, презентаций, внедрения и обучения председателей.
В этот момент окончательно понимаешь: продукт - это не приложение. Приложение - только один из артефактов продукта. Вокруг него должны появиться продажи, юридическая упаковка, поддержка, доверие, понятная цена и процесс внедрения.
И это, наверное, честное место, где сейчас находится проект: технически он уже перестал быть игрушкой, но бизнесово еще учится ходить.
Что осталось после вайба
В итоге у проекта вырос вполне реальный стек: backend на Node.js/TypeScript, Express и Prisma, PostgreSQL, Next.js/React для web/PWA, Android на Kotlin/Compose, iOS на SwiftUI, Docker Compose, Traefik, Let’s Encrypt, платежи, push-уведомления, документы, чаты, голосования и runbook-и.
Есть и понятная зона роста: Redis/BullMQ для очередей и distributed rate limiting, observability, S3 для файлов, security hardening, бэкапы, load testing. То есть все то, что превращает рабочий продукт в более зрелую промышленную систему.
Вайбкодинг заканчивается не тогда, когда появился первый прототип. Он заканчивается на localhost.
Дальше начинается продукт.
И здесь важно не перепутать: вайбкодинг не самоцель, а только инструмент. Очень сильный, местами удивительный, иногда опасно убедительный, но все же инструмент. Он помогает быстрее проверить гипотезу, собрать первый интерфейс, разобраться с кодом, пройти через деплой и не сойти с ума от количества незнакомых вещей.
Но сам по себе он не делает продукт.
Как и приложение не становится продуктом только потому, что у него есть backend, frontend, мобильные клиенты, платежи и пуши. Без упаковки, продаж, юридического статуса, поддержки, доверия и покупателей это все еще скорее технический артефакт. Большой, сложный, местами красивый, но не бизнес.
Наверное, моя главная трансформация за это время как раз в этом. Я начинал с идеи “сейчас навайбкодим приложение”. А пришел к гораздо более взрослой и сложной мысли: нужно сделать продукт.
Продукт, который кому-то нужен.
Продукт, за который готовы платить.
Продукт, который помогает председателям и жителям решать реальные повседневные задачи.
Продукт, который живет не только в репозитории, но и в договорах, презентациях, поддержке, внедрении и обратной связи.
Я его люблю, трепетно развиваю и очень хочу, чтобы он стал востребованным инструментом для цифровизации коттеджных поселков и СНТ.
Спасибо всем, кто дошел до конца статьи!
Комментарии (48)
Freeman_RU
26.05.2026 15:01Вы строите систему не для кп (которые в массе НКО), а для снт. Огромная юридическая разница.
Не раскрыто чем не устроили готовые решения, тот же ИНОМ?
AlexCoooper Автор
26.05.2026 15:01привет! решения на рынке есть, но рынок "тяжелый", когда общался с Домилендом, они сказали, что он мертвый. Тем не менее, ИНОМ, СНТ - Клуб, игроки есть, но их реализации выглядят незаконченными. У меня есть мотивация построить данный продукт и не свернуть на половине пути, такого опыта построения (от и до) у меня никогда не было, интересно, что из этого выйдет. Как минимум, не хотелось бы потом стыдиться, что какие то факторы оказались сильнее меня и я все бросил на уровне идеи.
Даже интересно, каждый раз сталкиваться с новыми обстоятельствами, делать вещи и шаги, о которых обычно не думаешь, как обывательFreeman_RU
26.05.2026 15:01Рынок не просто тяжёлый, его нет. Есть процентов 20 посёлков, которые готовы платить, все остальные хотят приложение уровня банковского за 5к в месяц. Поэтому каждый посёлок по факту строит свою систему на энтузиастах, ечди они есть.
WinLin2
26.05.2026 15:01Голосование через эту программу вряд ли признают легитимным, скорее это опросы общественного мнения. Государствр принудительно загоняет всех в мах, иначе большие штрафы. Голосования через госуслуги делают, подробности не знаю. Цель этой программы бухгалтерия, а для нее есть множпство платных и бесплатных программ.
serafims
26.05.2026 15:01Думаю, можно сделать голосование с подтверждением голоса через код в Макс боте.
AlexCoooper Автор
26.05.2026 15:01Вау, интересная история, и скорее всего она будет актуальной, сейчас голосования на гос услугах (мой дом) точно проводятся в ЖКХ, до СНТ пока вроде не добрались, но возможно это вопрос времени. Если это все появится, интересно было бы интегрироваться с Максом или ГИС ЖКХ, если у них будут публичные апи
vkomp
26.05.2026 15:01Обязательные по закону вопросы - это 6 категорий и 55 тем. В основном про внешние большие деньги. И местечковое голосование может быть легитимным, если собственники отдельным вопросом решат, что оно легитимное. А еще гос-ОСС "тяжелое и дорогое" - можно рассматривать местечковые системы как промежуточное для выработки альтернатив и предварительной оценки успеха.
Freeman_RU
26.05.2026 15:01Никаких проблем с голосованием. Закон об снт позволяет, даже простой электронной подписи хватает.
Главное чтобы в уставе была прописана такая форма.
vkomp
26.05.2026 15:01Спасибо за интересную статью. И важный опыт. Согласен, что рынок тяжелый. И приятно видеть, что кто-то рядом меняет его, засучив рукава и без нытья.
Я делаю похожую систему https://pro.deloset.ru - и тоже сложности с пилотным запуском. С обывателями уже наговорился вдоволь, далее думаю сосредоточиться на председателях. Но они еще и возрастные часто, и не хотят усложнять свою жизнь. Но с другой стороны - не толкаешься жопами с конкурентами.
Мой стек: сервер на Go, тонкий клиент PWA-React. Я сразу начал со сложных задач, и жахнул на них несколько лет: у меня возможно связывать сообщества между собой (соседние поселки), форумы для хранения документов и ролевая система доступа для каждого поселка, голосование тремя методами и упрощенный бухучет с двойной записью для местечковых проектов. Самое сложное - механизм связи сообществ, где бизнесовые партнерятся с потребительскими. Я хочу, чтобы не только новости частников, но и бизнесы присутствовали - в этом и есть бизнес-модель. И система профилей - по интересам и бизнесам, включая "по доверенности".
Потому долго делаю. И не вайбкодил, ии в чате юзаю. И только сейчас шлифую чаты. Потому что все собеседники пытаются сравнить с понятным - телеграм, и навороты на старте напрягают. И да, кодить и продавать - разные задачи. И интроверту тяжело в продажах.AlexCoooper Автор
26.05.2026 15:01Приветствую! Большое спасибо за поддержку! Ого, вижу серьезную проработку межхозяйственных взаимодействий, интересная история с бизнесом, я так понимаю, что бы подрядчиков и их услуги запустить в контур? нужно искать покупателей и не затягивать с реализацией сложной механики, сам уже быстрее бы запустился в своем пилотном СНТ, если бы не решил докручивать пару фитч, которые по факту не являлись критичными на момент запуска.
ИИ рекомендую использовать, в моем кейсе это стало отличным инструментом для ускорения разработки
Freeman_RU
26.05.2026 15:01А можно вопрос - зачем чаты? Вы же понимаете, что это сразу делает вашу систему подпадающей под ОРИ, а значит нужен СОРМ, и это уже совсем плохо. Зачем такие сложности? Если речь идёт про поселковые группы, то проще организовать их в той же телеге или макс. А если про чаты с сервисным службами, то проще это организовать через обычные заявки и не называть чатом, чтобы не связываться с ркн и ФСБ.
vkomp
26.05.2026 15:01Чат - это привычная форма диалога. Эталон. Все привыкли к такой форме. Я делаю достаточно универсальную штуку, которая не может не включать чат. Вообще базово отталкивался от форумов. И если выкинуть "лишний обвес", то на выходе будет тот же чат. Другими словами люди отвыкли писать абзацами, а разбивают на отдельные короткие предложения.
ОРИ - это речь про количество читателей. А если в "форуме" всего два человека - то это частный разговор. Если сотня - чат поселка. Заявка - несколько заинтересованных участников. Но я надеюсь дорасти до масштабов ОРИ - у меня запланировано, чтобы пользователь настраивал каналы новостей со многих сообществ. Поэтому это не проблема, а цель ;)
И главная мечта - географическая интеграция сообществ. Объединять поселки с общим забором и дорогой. Объединять МКД в микрорайоны.Freeman_RU
26.05.2026 15:01ОРИ - это про хранение в первую очередь. Почитайте почему исчезли чаты из банковских приложений. И стоимость СОРМ-а.
Вы так и не ответили зачем функционал мессенджера копировать и привлекать к себе лишнее внимание ркн и ФСБ.
vkomp
26.05.2026 15:01Не понял проблемы с ОРИ. Если я дорасту до этого, то это уже успех! А сейчас решаю просто привлечение. Будут люди - буду решать ОРИ. СОРМ - это про провайдеров, у меня просто сервер и хранение.
Объясняю зачем мессенждер - это про общение. Людей в ЖК и СНТ не собрать вживую. А если вдруг толпа, то это или "говорит один" или "говорят все" со всемозможными манипуляциями, что не ведет к доверию. Доверие - цель по управлению общим имуществом. К доверию ведут нужная глубина обсуждения (чат/форум - пишут как собственники так и внешние эксперты), внесение и оценка альтернативных решений (опросы с разными мнениями), открытая отчетность по финансам (хранение документов и рассылка).
Итого: как собрать мнения и обсудить альтернативы без сообщений? Чат - всего лишь способ вывода на экран. У меня привязка к электропочте, когда нибудь добавлю и номера телефонов.
Не наблюдаю проблем с ОРИ и спецслужбами - я сразу пишу, что автоматизирую публичное общение (доску объявлений поселка). Не планирую какого-то шифрованного хранения данных. Даже запланированы аккаунты муниципальных и федеральных госслужб и их присутствие внутри поселков.Freeman_RU
26.05.2026 15:01Почитайте на досуге: ФСБ потребовала от банков установить системы хранения переписки клиентов | Forbes.ru
> ФСБ напомнила, что они подпадают под статус организаторов распространения информации (ОРИ), так как в их мобильных приложениях пользователи могут обмениваться сообщениями. И поэтому в течение полугода банки должны хранить содержание переписки клиентов. С января 2026 года срок обязательного хранения данных о переписке и сведений о пользователях будет увеличен до трех лет.
Вы же понимаете, что играть в игры с нашим государством - это такое себе. Провайдеров победили, теперь вот банки, дальше - все остальные. Я бы не рисковал. Функционал закрывается любым существующим мессенджером с помощью закрытых групп. Еще вопрос как вы исполняете 152-ФЗ.vkomp
26.05.2026 15:01Спасибо за заботу, но... нужный функционал не закрывается мессенджером. Ну никак! Сами недостатки мессенджера привели к созданию своего сервиса:
1. Не все собственники в мессенджере - их просто нет, но они могут участвовать в сообществе оффлайн или через почту.
2. Не все в мессенджере собственники - полно супругов, детей, арендаторов и засланных казачков. А как тогда учесть мнения только собов, ну?
3. Нужны не только собственники - в выработке альтернатив нужно привлечь экспертов. И выделить мнение эксперта.
4. Нужно назначить доли участникам - у кого-то однокомнатная, у другого четырехкомнатная, и их доли не равны. Еще вариант - от какой-то квартиры один соб, от другой пять долевщиков!
5. Как учесть доли отсутствующих собственников по целым объектам?
6. Бесконечная лента не годится для вдумчивого обсуждения. Какие-то вопросы не решаются жалобой мэру. Форум - наше всё.
7. Как разграничить доступ к файлам по роли собственника?
и т.д и т.п.
И вообще моя цель - объединять людей и сообщества в разных конфигурациях как в реальной жизни. Я не нашел такого мессенджера - придумал свой. Проще ОРИ наладить, чем делать операцию на сердце через задницу (делать через продвинутое api запрещенного мессенджера).
house2008
26.05.2026 15:01В Тайланде снимал жилье, на ресепшене QR код -> ставишь апу -> вводишь квартиру (ресепшен подтверждает что это я) -> в апе уже оплачиваешь воду / смотришь новости и чаты по дому / букаешь фасилитиес / уведомления что пришла почта - очень удобно. Кто не хочет ставить, то можно через обычный месседжер (Line). Отсюда вывод, нужно заходить сверху, чтобы всем навязать использование.
AlexCoooper Автор
26.05.2026 15:01Все верно, в данном случае нужно в первую очередь продавать ценность именно председателям СНТ, т.к они драйверы принятия таких решений. Своему председателю, к слову, довольно легко получилось подать идею, ведь все взносы и услуги он ранее записывал в тетрадке, высылал сообщения с qr в мессенджере и потом подбивал все в эксельке для передачи бухгалтеру, приложение очень сильно срезает ему эту рутину
VsBirdEye
26.05.2026 15:01Автор, рекомендую рассмотреть переход с infra runbook и деплоя через агента на классические ci/cd пайплайны - например, на базе своего gitlab ce сервера с gitlab runner'ом. В этом варианте деплой или релиз можно делать как автоматически по коммиту, так и с ручным подтверждением. Агенту можно выдать MCP к gitlab серверу для разбора логов или руления процессом деплоя при необходимости.
На мой взгляд плюсы - экономия токенов на детерминированных процессах, возможность быстрого отката. Минусы - еще пара элементов в инфраструктуре.
Tanasy
26.05.2026 15:01Как много лишних телодвижений ради одного коттеджного поселка. Можно было просто сделать простенький сайт с мобильной версией и не парится так.
AnatolyEmelin
26.05.2026 15:0111 лет живу в коттеджном поселке. Проект весьма интересный и полезный, но... Пока это пет проект , то есть для себя и пока не надоело. Как только захотите в прод , то возникнет много юридических тонкостей связанных с приемом платежей в пользу ТСН, СНТ все может быстро закончится. Дело нужное , но не благодарное. Сил, терпения, а опыт просто супер.
AlexCoooper Автор
26.05.2026 15:01Спасибо за поддержу! Юридических нюансов будет действительно немало, но по платежам все в целом не сложно, уже настроил интеграции с Т-Банк и Юкасса, приложение в данном случае выступает только как брокер, при этом все платежи идут через интернет эквайринг зарегистрированный именно на конкретный СНТ, т.е моя платформа через себя деньги никак не пропускает, лишь служит "оберткой"
AnatolyEmelin
26.05.2026 15:01Если в ТСН 100 участников, юкасса может затребовать их паспортные данные... Вам что бы их собрать для передачи им потребуется ...)))
Freeman_RU
26.05.2026 15:01Вы что-то путаете. У нас по 400+ в нескольких поселках, никто ничего не требует (правда, не СНТ, но есть не мой СНТ где через ИНОМ принимают, и там вообще 500+). Это всё равно, что магазин - если у него под тысячу клиентов что-то покупает ему что, с каждого паспортные данные требовать?
unitcraft
26.05.2026 15:01Близко по ощущениям. У меня не SaaS, компилятор — но та же штука: агенты неделями пишут код, всё локально работает. А когда первый раз показал репозиторий знакомому, он спросил «и что я с этим должен делать?». Само наличие компилятора без документации, примеров и объяснения зачем оно нужно — никому не интересно. И вот это уже агентам не отдашь.
itcry
26.05.2026 15:01Отличная статья!
Прошел примерно по Вашему пути (смысл прилаги только другой. Менеджерская операционка. И вот решил я сделать внутри компании чаты. Так же сначала с пва, понял что это не торт и так же перешел на нативную.
Но если честно, уже второй месяц борюсь с нативной именно в области мессенджера.
Сначала все летало просто. Потом накинул шифрование данных, работу с 1000+ чатами, фото, аудио/видео звонки и… все посыпалось. Уже месяц точно занимаюсь наведением красоты. То сообщения уходят по 1-3 сек при соединении с сервером в 20мс, то скрол откидывается к последнему сообщению.
На данный момент в мессенджере реализовал скрол списка чатов с бесшовной подгрузкой (хоть список из 1000 чатов будет листаться плавно, аккуратно и не нагружать железо). Но вот внутри чата пока еще есть мелкие проблемы, которые не дают ощущения стабильного, современного мессенджера.
Вам удалось решить подобные проблемы? (Уверен, что на каком-то этапе они точно встречались)
AlexCoooper Автор
26.05.2026 15:01Спасибо! Да, “простой чат” очень быстро перестает быть простым. У нас масштаб пока другой, поэтому 1000+ чатов не основной сценарий, но проблемы со скроллом, клавиатурой, пушами и медиа уже знакомы. Я специально не пытаюсь строить универсальный мессенджер: для нас чат — часть операционного контура поселка. Сейчас есть пагинация сообщений, личные чаты, топики, push, медиа и кэш на Android/IOS, но список чатов пока не рассчитан на 1000+ комнат, а web-историю нужно будет виртуализировать. Следующий технический шаг — Redis/BullMQ для фоновых уведомлений, WebSocket/SSE для realtime и S3-хранилище для медиа. Звонки и E2E пока сознательно не берем, иначе продукт утонет в мессенджере вместо цифровизации поселка.
lokrusta
26.05.2026 15:01За статью спасибо!
Несколько мыслей в тему:
1. Какой потенциальный охват рынка? Сколько будет стоить подписка на приложение? Кажется, для СНТ на 100 человек и стоимости подписки, скажем, 300-500 в месяц не очень интересно. А если распространять приложение глобально, там уже другой маркетинг нужен
2. Для платного сервиса нужна поддержка. Вы сами будете ей заниматься?
3. Как вы тестируете разработку? Например, я делаю на вайбкодинге opensource библиотеку и при разработке опираюсь на интеграционные тесты, поднимающие в docker всю инфраструктуру + отдельные приложения, которые одновременно демонстрируют работу библиотеки и используются для нагрузочного тестирования. Но, у меня нет интерфейса - у вас он есть причем под разные платформы
gerbert_MX
Ну собственно как я и думал - "необходимость" в приложениях это чисто менеджерская фишка
Сделайте нормально сайт. НОРМАЛЬНО. Включая и для мобильных платформ. И ВСЕ.
Никому нахрен не упало 100500 приложений и столько же сайтов. Просто один источник истины но сделанный нормально.
Понятно что на сайте не заработаешь ведь адблокер порежет всю рекламу, но такова реальность. Попытка заработать на клиенте в гарантировано комическом продукте прекрасно характеризует сам продукт.
Freeman_RU
Ты вы ошибаетесь. Обычному обывателю нужно приложение, ему так привычнее. Они не знают про всякие там Избранное и PWA, а объяснять пользователю как установить PWA том же iOS - это боль и страдание. Обычномв человеку нужен привычный инструмент - жмакнуть пальцем на рабочем столе. Все эти веб-сайты для них высокая материя. Тот же Домиленд так выстрелил.
AlexCoooper Автор
Все верно, PWA максимум годится для отладки или тестовой демонстрации идеи. PWA вроде и не сложно установить, но как не крути, пользователю это не удобно. А сами ощущения от использования PWA и нативного клиента просто драматические.
Freeman_RU
Вы просто не видели хорошего PWA. Сейчас можно построить подноценнеоп приложение (если не нужен доступ к железу телефона) - всё что у вас на скринах легко делается через PWA. Но политика iOS по их установке и огромное количество браузеров на андроид делают pwa настоящей головной болью.
AlexCoooper Автор
Все, что на скринах в целом дублируется 1-1 и в PWA, разница возникает, когда начинаешь этим всем пользоваться, то чаты загружаются с микролагом (потому что не кешируются), то свайпов не хватает. Возможно, конечно я не добился идеальной реализации, но когда смог сделать девелоперские аккаунты для размещения в магазинах, понял, что лучше делать нативку.
Freeman_RU
PWA шикарно кэширует данные, не хуже нативных. Со скролом это скорее к css вопрос и что там нейронка нагенерила. Для одного-двух посёлков держать аккаунты в сторах выходит очень дорого.
gerbert_MX
Эти обычные обыватели сейчас с нами в одной комнате?
Для поселки-аля-дачи нужно что бы оно было доступно 24/7 и работало на чем угодно и как угодно. С приложениями вечно "это у нас на сайте" или обратное "это только в приложении" и как вишенка "все платформы" оказываются далеко не всеми, особенно если это делается малой командой или вообще в одну каску.
Я даже не говорю про PWA - без офлайн-функционала когда он действительно нужен от приложения, PWA избыточен. Плюс в 90% случаев PWA не умеют делать. Очень часто встречается две крайности - кривая настройка из-за чего без сети оно не будет работать (а иногда и обновления если что то залипло в кеше не будет) или наоборот все настолько "хорошо работает" что первый запуск сайта нужно ждать минуту пока в память загрузятся все 100500 зависимостей на пол гига в сумме
Приложения обычно продвигают только тогда когда кровь из носу нужно зарабатывать на пользователях. Во всех остальных ситуациях для сервисов которые открываешь раз в месяц сайта достаточно и это нормально.
Ниша приложений в сложном офлайне (и то есть PWA, на сейчас оно и камеру поддерживает и вибро и много что еше) или опять таки сложные потоковые операции (тщательная верификация клиента для работы, управление периферией устройства, работа с памятью и тд)
AlexCoooper Автор
Я соглашусь, что вот прямо здесь и сейчас, учитывая рынок и мою стартовую точку, было бы достаточно веб версии. Пилить нативные клиенты, исключительно мой пунктик, ну не заходит мне PWA на уровне взаимодействия) это фактор конечно возможно и не играет большой роли для конечного пользователя.
С другой стороны, после того, как я разобрался в мобильных клиентах и специфике публикации приложений, у меня не составляет труда их актуализировать. В md. заложены правила, все новые фитчи обязательно валидируются на соответствие текущим реализациям PWA, Android, IOS, релизы всегда выходят одновременно на все платформы
gerbert_MX
то у вас просто большого охвата не было
начиная от неизвестных андроид-китайцев которыми пользуются бабки и заканчивая свяким пограничным когда старая версия прошивки у айфона и именно на этой версии есть баг/конфликт ели запускать "новое" приложение. Про всякие виндовсфоны и прочее вообще молчу.
Я когда то объяснял меджерам что для холодильников и смарт-телевизоров есть сайт потому что мы не можем поддерживать все модели и площадки одновременно.
Freeman_RU
Для посёлков бабки и смарт-телевизоры не интересны совсем. У первых нет денег, вторыми никто не будет пользоваться в здравом уме, а в не здравом вообще не интересуют как клиенты, опять же. Так что в посёлках примерно одно и тоже - более-менее современные телефоны, подавляющее количество на ios (если мы говорим про кп или приличный снт, а именно они способны покупать такой софт).
gerbert_MX
да да, вы ж специалист
просто напоминаю что мир гораздо больше видимого вами пузыря и то что вы видели в одном из поселков (и скорее всего со стороны) не означает что везде так
Freeman_RU
Ну раз вы начали мерять длинну, то ок. Контакты в порядка 150 разных посёлков, 3 разных партнёра, контакты с провайдерами, производителями сбора телеметрии, видеонаблюдения, скуд, приложений для поселков, и все говорят одно и тоже. Сам занимаюсь 10 лет поддержкой посёлков уровня бизнес, сейчас 3, в ближайших планах взять еще 5, есть своё приложение (пока что pwa к слову, но планирую уходить в натив). Нормальная выборка? Какой у вас опыт вы так и не сказали, хотя я несколько раз спрашивал. Просто вы типичный ИТ-шник, в хорошем смысле, но обычные люди мыслят совершенно иначе. Особенно те, у кого свой дом. Я это на своём опыте прошёл, тоже думал, что сайт нужен всем (тм) и закроет все потребности. У вас еще всё впереди :)
Freeman_RU
Да, они живут в посёлках, которые на обслуживании. Самая большая проблема - запомнить адрес сайта. Даже если сайт по имени схож с названием посёлка. Для около-ИТшников это кажется странным, но для обычных пользователей это так.
И я выше приводил пример - самое успешное приложение для мкд и посёлков (домиленд) не имеет сайта для жителей вообще, только приложение.
gerbert_MX
QR-код - `просто существует`
расклеивается банер по поселку и все
с приложением тоже нужно название помнить. а если уж помнишь название то опять таки сайт или приложение нет разницы, если сайт так же гуглится по названию
Freeman_RU
Зачем название помнить?? Один раз поставил, и всё. Я вам говорю отзывы десятков людей, реальных пользователей.
Ну а qr это очень смешно)) почему то мне кажется, что вы не живёте в кп))
gerbert_MX
Из той же рубрики - "один раз закладку сделал и все"
Freeman_RU
Да, вы мыслите как адвансюзер. Я тоже так думал. Потом пришла суровая реальность. Не будет чувак на бмв х7 и домом на 600 квадратов осваивать вкладки. Суровая реальность. Им подавай приложение, потому что они так привыкли. И они самые платежеспособные - именно они заказывают кучу допуслуг в посёлке. Знающие про вкладки обычно и газон сами стригут.
gerbert_MX
У чувака на BMW обычно есть человек, что этим всем занимается
Для таких людей важна стабильность и беспроблемность - ему не важно как оно там работает и тд. Он обращает внимание если есть проблемы и/или не работает когда внезапно понадобится.
Freeman_RU
бмв х7 и 600 квадратов это не тот уровень, это менеджер в фирме в Москве, или владелец небольшого бизнеса. Он сам кнопки жмёт, в том числе заказать пропуск, вызвать сантехника, газон постричь. Т он не в курсе про избранное, потому что у него куча приложений на телефоне, и долей в 80% это apple. Сколько вообще посёлков видели с точки зрения ИТ? Почему то мне кажется, что ноль?
opusmode
Как раз строго наоборот - людям нафиг не упали сайты. Им нужно одно, конкретное приложение, под одну, конкретную фигню.
Мобильные ОС давно самые распространённые в мире, мобильный траффик самый объемный, а мобильное приложение - основная точка касания. Если вы сделали сайт и не сделали приложение, вы автоматом выстрелили себе в ногу