От полотенец до Google Play: почему это оказалось дольше, чем обещают на курсах по вайбкодингу

Часть 1 – Личный опыт: от бытовой идеи и технического задания до Flutter, Cursor, ChatGPT и собственного релиза в Google Play.

Однажды, в очередной раз меняя полотенца, я поймала себя на мысли: а когда именно я повесила эти? Вчера, два дня назад или три? А когда мы в последний раз меняли зубные щётки? Как давно носим эти ботинки? Сколько лет нашей кофемашине, не пора ли задуматься о новой?

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

Немного контекста. Больше десяти лет я работала в IT и участвовала в создании цифровых продуктов для города и государства. Суть работы была в том, чтобы упростить людям взаимодействие с госсервисами: то, что ещё 5–10 лет назад отнимало у граждан время, усилия и нервы, постепенно на моих глазах превращалось в понятные цифровые процессы.

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

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

Так родилась идея Renew That. Готовое приложение уже лежит в Google Play, а подробнее о том, как оно работает, — на сайте проекта.

Придумать приложение и реализовать его — две совершенно разные задачи.

Работая в IT, я хорошо усвоила непреложную истину: «Без ТЗ результат — ХЗ». Поэтому первым делом я описала, что именно хочу получить.

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

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

Параллельно я пробовала рисовать первые макеты экранов. Какие-то решения нравились, какие-то нет. Я правила макеты, уточняла требования и снова возвращалась к ТЗ. Макеты были типичной красивой картинкой от Chat GPT, но как перенести это в реальное приложение?

Этот процесс оказался важнее, чем я думала: нужно было не только придумать, как приложение выглядит, но и последовательно разобраться, как именно человек будет им пользоваться. Очевидно, что понимание последовательности экранов сильно упрощает представление о фичах, которыми хочется наполнить приложение. Поэтому лично для меня создание карты экранов – важнейшая часть проектирования. Ее можно упростить до описания App Flow.

Main App Flow

• Home screen → list of groups+items without group

• Tap group → list of items

• Tap item → item details + history

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

next_replace_date = last_replaced_at + replace_in_days

is_overdue = current_time > next_replace_date

При Replace Now:

last_replaced_at = current_time

next_replace_date = current_time + replace_in_days

is_overdue = false

Когда стало понятно, что я хочу сделать, возник следующий вопрос: на чём и чем писать код?

Я обсуждала варианты с нейросетями и в итоге остановилась на Flutter. На старте проекта мы ориентировались исключительно на Android. Поэтому кроссплатформенность сама по себе не была решающим аргументом. Но для меня была очень важна свобода проектирования интерфейса, простая интеграция с Firebase

Примерно тогда же знакомые разработчики посоветовали попробовать Cursor — IDE со встроенными AI-инструментами. До этого на компьютере уже стоял PyCharm, установленный ещё во время изучения Python. Но для нового проекта я решила попробовать другой подход.

Первый результат оказался одновременно впечатляющим и отрезвляющим. Я передала инструменту ТЗ и краткое описание структуры проекта — и базовый Flutter-проект появился буквально за один вечер.

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

Стало понятно, что впереди гораздо более кропотливая работа.

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

У меня были макеты, ТЗ и представление о том, как должен выглядеть каждый экран. Я последовательно описывала нужную функциональность, готовила промпты, получала код от ChatGPT, переносила его в проект и проверяла результат.

Если экран выглядел не так, как я ожидала, я уточняла требования и вносила правки. Если выяснялось, что первоначальный сценарий неудобен или неполон, возвращалась к ТЗ.

Так интерфейс и логика собирались постепенно, небольшими частями.

Это не история о том, как я нажала одну кнопку и получила готовое приложение. Скорее, я выстроила собственный процесс работы с AI: постановка задачи → генерация → проверка → исправление → повтор.

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

Но этого оказалось недостаточно, чтобы избежать ошибок.

В процессе разработки регулярно появлялись ошибки. Я показывала их ChatGPT, анализировала предложенные варианты и пыталась понять, где искать причину.

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

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

Симптом. Одной из самых неприятных ошибок стала проблема создания дома. А это самый первый шаг пользователя. В Renew That дом — основная единица организации данных: внутри него предметы, группы и участники семьи. Поэтому создание дома — не просто запись в базе, а операция, от которой зависит почти всё приложение.

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

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

• households — сам дом и его данные;

• household_members — связь пользователя с домом, включая роль.

При создании дома приложение должно не только сохранить его, но и назначить создателя владельцем (owner). Только после этого пользователь получает доступ к дому через механизм членства. Но ошибку в коде найти по-прежнему не удавалось. Я попросила Cursor ( разобрать весь механизм, и он выявил следующее:

1. Данные загружались асинхронно через Firestore.

2. При ошибке поток данных мог перейти в состояние hasError.

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

4. Экран находился во вложенной навигации внутри IndexedStack, где использовались const-виджеты. Поэтому возврат с экрана создания не гарантировал повторного запуска логики загрузки.

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

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

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

Вместе с ChatGPT мы сформулировали простые правила.

Владелец дома (owner):

• автоматически назначается при создании дома;

• может приглашать новых участников;

• может удалять участников;

• может удалить сам дом.

Участник (member):

• может работать с содержимым дома;

• может добавлять, редактировать и удалять предметы;

• может создавать и изменять группы;

• может отмечать обновление предметов и корректировать сроки замены;

• не может удалить дом или управлять составом участников.

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

Так, постепенно, я поняла: AI не снимает с меня ответственности за результат. Он помогает писать код, объяснять ошибки и предлагать варианты, но не гарантирует, что решение корректно именно в контексте моего проекта.

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

От первой версии ТЗ до первого полноценного тестирования прошло около полугода.

Это не значит, что я посвящала проекту всё время. Параллельно я вышла из декрета и вернулась к работе. Разработка Renew That шла в свободные часы — между рабочими задачами и семьёй.

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

На этапе тестирования всплыли проблемы, которые невозможно выявить по сгенерированному коду или отдельным экранам.

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

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

Именно здесь я особенно остро почувствовала разницу между прототипом и продуктом.

По мере роста проекта мне стало не хватать возможностей бесплатной версии Cursor, и я перешла на Pro (24$/мес). ChatGPT при этом продолжала использовать бесплатно.

К тому моменту я пробовала и Claude: просила помочь с кодом, разобраться с ошибками, сгенерировать визуальные материалы. Но в рамках моего проекта результаты не всегда оказывались достаточно понятными и полезными, поэтому основным инструментом он не стал.

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

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

После первого тестирования начался ещё один долгий этап: исправление ошибок, повторные проверки и подготовка релиза.

Я выпускала приложение как частный разработчик, поэтому мне предстояло пройти закрытое тестирование Google Play: привлечь двенадцать тестировщиков и организовать проверку перед получением доступа к публикации.

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

Помимо пользовательских замечаний, возникали и технические вопросы: подпись приложения, сертификаты, Google Sign-In, подготовка сборок. Некоторые проблемы заставляли возвращаться к настройкам Firebase или Android-проекта, хотя казалось, что сам функционал готов.

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

В итоге Renew That прошёл закрытое тестирование и опубликован в открытом доступе в Google Play.

Сейчас у Renew That есть первые пользователи и первые скачивания. Для меня это важный момент: идея из бытовой ситуации превратилась в приложение, которым пользуются другие люди.

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

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

Буду ли я продолжать его развивать? Однозначно да.

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

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

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

И наконец, я убедилась: не обязательно ждать, пока появятся все нужные навыки, чтобы попробовать реализовать свою идею. Можно начать с того, что уже умеешь, постепенно осваивать новое и использовать AI как помощника.

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

И, кажется, это только начало. В следующей части я попытаюсь рассказать о том, как настраивала Firestore Security Rules, и какие пугающие email приходили мне от него)