Я только что выполнил свой первый вайбкодинг-заказ по разработке небольшого интернет-магазина. Изначально задача выглядела понятной: каталог, корзина, админка, оплата, деплой. Казалось, что это несложный CRUD-проект плюс дизайн по референсам заказчика.

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

1. Разрабатывал только локально, на VirtualBox

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

Но мой VirtualBox не был доступен из внешнего интернета. Поэтому через несколько дней пришлось разворачивать staging-сервер на VPS для полноценного тестирования.

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

2. Слишком поздно занялся боевым сервером

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

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

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

3. Неправильно организовал доступ к хостингу

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

Не успел я довести настройки до конца, как клиент добавил 2FA по email. В итоге доступ пришлось восстанавливать через лишние согласования.

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

4. Недооценил сложность интеграции с банком

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

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

5. Не определил процесс согласования дизайна

По ходу проекта я так и не пришел к окончательному ответу, что эффективнее:

- либо сначала показывать заказчику сгенерированные макеты или референсные картинки;
- либо сразу писать черновой код фронтэнда и показывать реальные экраны из браузера.

У обоих подходов есть недостатки.

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

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

6. Не проговорил с заказчиком реальную стоимость доработок

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

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

Я сделал вывод, что «мелких правок» не бывает. Даже минимальное изменение, состоящее из одной строки, в моем случае означает:

- открыть проект и рабочую среду;
- переключиться на актуальную ветку;
- внести изменение;
- проверить его локально;
- проверить на staging;
- отправить скриншот заказчику;
- получить ОК на обновление;
- выкатить обновление в прод.

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

7. Недостаточно подумал о безопасности

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

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

8. Переусложнил архитектуру

Я сделал магазин в двух вариантах: как обычный сайт и как Telegram Miniapp. Заказчику я представил это как преимущество. Но на практике это оказалось лишним усложнением.

Две платформы означают больше условий, больше развилок в логике, больше тестирования и больше точек отказа. Сейчас я бы так не делал. Для небольшого проекта разумнее выбирать что-то одно: либо обычный сайт, либо Miniapp.

С Telegram Miniapp есть и дополнительная проблема: для нормальной работы Telegram API по причине блокировок лучше использовать зарубежные серверы. Но здесь сразу возникает вопрос соответствия требованиям по хранению персональных данных. В результате архитектурное решение перестает быть чисто техническим и быстро упирается в юридические ограничения и сетевую доступность.

9. Столкнулся с юридическими рисками

Я реализовал авторизацию через Google, а потом вышел закон, который запрещает это в России. Теперь авторизацию, вероятно, придется переделывать.

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

10. Недостаточно вложился в нагрузочное тестирование

Пока мой сервер с 2 ГБ памяти справляется с текущим объемом нагрузки. Но это скорее наблюдение, чем реальная уверенность в запасе прочности.

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

Что я вынес из этого проекта

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

Спасибо, что дочитали до конца.
Надеюсь, этот список поможет вам (и мне) не наступить на те же грабли.