Как мы строили «Договорились». Часть 2: от идеи до прода за 48 часов

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

Угол, который мы срезали сознательно

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

Мы её пропустили. И не по запарке — осознанно. Логика была такая: продукт настолько простой и цельный, что дешевле его собрать целиком и выкатить, чем неделю проверять на словах. Сам факт живого прода и станет проверкой — придёт второй человек по ссылке или нет. Риск мы записали прямо в план, чтобы потом не делать вид, что так и было задумано случайно.

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

К концу второго дня продукт работал у нас на компьютере целиком. Оставалось «просто выложить на сервер». Вот это «просто» и оказалось отдельной историей.

Баг первый: бот, которому забыли дать половину мозга

Чтобы выложить продукт на сервер, его сначала пакуют в «коробку» — со всем, что нужно для работы. У нас таких коробок несколько, и одна из них — для бота, который шлёт напоминания.

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

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

Баг второй: пароль, который лежал не там, где его искали

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

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

Что это дало

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

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

И да — по итогу второй человек по ссылке пришёл. Ставка «собрать и выкатить вместо недели ручной проверки» себя оправдала. Но это уже к слову.

Что забрать себе

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

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

Дальше: продукт жив, но что делает его по-настоящему хорошим — это его голос. Как мы научили приложение напоминать о долге, не вызывая чувства вины, и приручили самую опасную фразу в отношениях.