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

1. Постоянно делать предложения лидам

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

Рабочий пример:

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

 Нерабочий пример:

Добрый день! Хотел с вами встретиться, будет ли вам удобно в ближайшие дни, или на неделе?

2. Показывать демки

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

Примеры:

• Послал одному из потенциальных заказчиков маленькую демку (меньше часа вайбкода) - получил в ответ "Было бы интересно посотрудничать".

• Другому вместо демки послал голосовое - не получил в ответ ничего, кроме дохлого лайка.

3. Фиксировать договоренности

После того, как о чем-то договорился с заказчиком, фиксирую договоренности письменно. Это очень помогает. Мы общаемся в Телеграм, и я просто делаю кратенькое резюме того, к чему пришли. Такая фиксация полезна не только заказчику, но и мне самому. Через неделю уже можно забыть какие-то детали, а тут все лежит в двух абзацах и не надо спорить о том, кто что понял.

Пример:

Фиксирую ТЗ, которое обсуждали вчера. Срок - 3 недели с момента предоставления вами референсов, стоимость такая-то. Отдельно оплачиваете размещение на сервере и доменное имя. Сайт будет адаптирован под мобильные телефоны, а админка - под ноутбук.

4. Писать клиенту о промежуточных результатах

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

Пример:

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

5. Привлекать помощь

Помните изречение "Если хочешь сделать все идеально, делай все сам"? Вот и забудьте его. Я понял, что просто не успею все сам и в срок. Либо успею, но устану, как черт. Оно мне надо? Я не для этого уходил из найма, чтобы упарываться и выгорать.

Лучше уж я буду работать 3-4 часа в день, но с огоньком. И поэтому мне нужна помощь - партнера, друзей, кого угодно. В моем случае фриланс - очень социальная история. Чем больше общаюсь с людьми, которые мне помогают, тем быстрее прогрессирую сам.

6. Разработку вести локально, на VirtualBox

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

Можно было бы разрабатывать прямо на staging-сервере. Но пришлось бы ставить туда что-то типа screen, чтобы не иметь проблем с закрытием сессий. На локальной VirtualBox такой проблемы нет.

7. Делать все как можно проще

Книга Д. Канемана "Думай медленно, решай быстро" всегда у меня на видном месте. Там красной нитью проходит тема про когнитивную простоту. Поэтому я стараюсь разрабатывать максимально интуитивный интерфейс. Дизайн, архитектура, элементы управления - ничто не должно вызывать вопроса "А как этим пользоваться?" Чем меньше человеку приходится догадываться, тем лучше выглядит сайт.

8. Взять у заказчика отзыв

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

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

 9. Порефлексировать на тему проекта

Написать статью или отчет. Что пошло так, а что не так. Прям скрам-ретроспектива, блин. Но смысла тут намного больше, потому что нужно устаканить в голове вещи, которыми занимался впервые.

Пока не выпишешь опыт словами, он остается мутным ощущением. А когда пишешь – логика кристаллизуется на глазах.

10. Не стесняться напоминать о себе

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

Главное - напоминать не в формате "ну что там?", а с пользой. Например, принести новую мысль, демку, пример, уточнение. Тогда ты не просто дергаешь человека, а двигаешь разговор вперед.

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

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

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