Вайбкодинг заканчивается на localhost: как я строю SaaS для цифровизации коттеджных поселков с Codex

Тетрадка председателя

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

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

Дальше были только вопросы:

Где посмотреть начисления? Надо поискать в чате. Кому оплатить? Председатель скинет реквизиты. Где протокол собрания? Кажется, был PDF пару месяцев назад. Кто должник, кто голосовал, кто отправлял заявку? “Как-нибудь ведем”.

Важная оговорка: я не разработчик. Я работаю в IT, занимаюсь операционным менеджментом, раньше был бизнес/системным аналитиком. Поэтому слова вроде API, база данных, миграции, роли пользователей, интеграции и критерии приемки мне были знакомы.

Но знакомы они были скорее теоретически. Одно дело — обсуждать архитектуру на встрече, описывать процессы или писать требования для команды. И совсем другое — самому поднять сервер, подключиться по SSH, разобраться с Docker, понять, почему миграция не применилась, почему приложение работает локально, но падает на VPS, и почему push-уведомления не приходят.

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

localhost:3000

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

Разумеется, это была иллюзия. Как оказалось, на локалхосте далеко не уедешь.

Дальше понеслось: виртуальные машины, SSH, Git, Docker Compose, Traefik, домены, HTTPS, переменные окружения, Prisma-миграции, пересборка контейнеров, логи и rollback. Вайбкодинг из игрушки начал превращаться в инженерный процесс.

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 месяцев. Но результат радует, на данный момент приложения доступны в обоих сторах.

Что сейчас умеет приложение

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

Кроме этого, в приложении есть документы, профиль, 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, мобильные клиенты, платежи и пуши. Без упаковки, продаж, юридического статуса, поддержки, доверия и покупателей это все еще скорее технический артефакт. Большой, сложный, местами красивый, но не бизнес.

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

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

Я его люблю, трепетно развиваю и очень хочу, чтобы он стал востребованным инструментом для цифровизации коттеджных поселков и СНТ.

Спасибо всем, кто дошел до конца статьи!