Вайбкодинг выбрал мне стек. Пришлось всё переделать, когда решил продавать в России

Когда собираешь продукт с ИИ, стек выбираешь не ты (если ты конечно сам его в явном виде не запрашиваешь). Ты просто говоришь «нужна авторизация по почте» или даже просто «нужна авторизация», а в ответ получаешь готовый кусок с конкретным сервисом внутри. Говоришь «нужен деплой», получаешь Vercel. Нужна база данных, получаешь Supabase. И тд. Хостинг, платежи, почта, аналитика: на каждом шаге коллега с именем из двух букв предлагает вариант, который просто работает.

Все эти сервисы правда хорошие и как правило удобные. Проблема не в них.

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

Почему агенты предлагает именно это

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

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

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

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

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

Что именно упирается в границу

Три вещи, и все три продуктовые в основном и в меньшей мере технические.

Персональные данные. 152-ФЗ требует, чтобы данные россиян сначала записывались в России. Это не про «где красивее», это про то, может ли сервис вообще легально работать. Зарубежное облако с базой ответ даёт сразу, и ответ отрицательный.

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

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

Вайбкодинг выбрал мне стек. Пришлось всё переделать, когда решил продавать в России

Ни один из этих вопросов не решается за вечер, и ни один не является техническим. Это всё вопросы уровня «что за продукт и для какого рынка».

Чего стоил переезд лично мне

Три дня работы, с 28 по 30 июля. Само по себе немного, и если бы всё свелось к трём дням, этот пост был короче и скучнее если бы был вообще.

Дороже оказалось другое: часть вещей сломалась не там, где я смотрел.

Данные переехали, а обработка нет. Я перевёз базу, прогнал все тесты, все зеленое, отметил в чеклисте, что всё в порядке, поехали дальше. Это было неправдой примерно месяц: одиннадцать серверных обработчиков остались на зарубежной площадке (Vercel) и продолжали принимать те самые персональные данные. Формулировка в плане была написана из намерения переезда, а не из списка того, что реально где выполняется. Хранение и обработка это два разных вопроса, и второй закрывается отдельно.

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

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

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

Если переезжать всё-таки придётся

У многих ситуация уже такая: продукт написан, стек западный, переезжать надо. Дальше по порядку и коротко, не как инструкция, а как список мест, где я сам споткнулся. В общем старый добрый fail to plan, plan to fail

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

Отдельным пунктом список внешних сервисов. Почта, платежи, аналитика, капча, хранилище. По каждому один вопрос: работает ли он в РФ и остаётся ли он вообще. Часть переедет, часть заменится, часть останется как есть, и это нормально. Плохо, когда состав этого списка выясняется по ходу.

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

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

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

Вайбкодинг выбрал мне стек. Пришлось всё переделать, когда решил продавать в России

Что стоило решить до первой строчки кода

Если коротко, то один вопрос: продукт продаётся в России или нет.

Ответ «да» меняет не код, а список сервисов, из которых код собирается. И принимать это решение дешевле в тот день, когда его ещё никто не принял за тебя, чем через три месяца, когда вокруг чужого API уже написана половина логики.

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

Вайбкодинг выбрал мне стек. Пришлось всё переделать, когда решил продавать в России

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

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

Свой продукт я в итоге перевёз целиком, и сейчас он собран под РФ реалии, требования и законы. Но три дня и месяц с неверной строчкой в плане я бы предпочёл потратить иначе.

Интересно, у кого как. Если продукт делался с ИИ и продаётся в России, стек изначально выбирался осознанно или тоже пришлось переигрывать по дороге?