Пет-проекты, которые не умерли: как на вайб-кодинге довести сайд-проект до живых пользователей
Пет-проекты умирают не от плохих идей, а от срыва исполнения: около 80% сайд-проектов не доходят до релиза. Доживают те, у кого узкий скоуп на одну живую функцию, ранняя выкатка чужим людям (а не друзьям) и внешняя подотчётность. Вайб-кодинг ускоряет стройку, но не спасает от главной ловушки - бросить на 80% готовности ради новой идеи.
Около 80% сайд-проектов не доходят до релиза. Почему пет-проекты бросают на 80% готовности, сколько их тянуть одному (git-статистика моих семи) и где помогает вайб-кодинг.

В статье · 8 разделовразвернутьсвернуть
У меня есть личное кладбище проектов. Штук пятнадцать репозиториев, которые начинались с "хэй, так этож продукт!", а заканчивались коммитом трёхмесячной давности и стыдливым archive. И это не потому, что я плохой разработчик. Это потому, что доводить проект до живых людей - совсем другой навык, чем его начинать. Начинать кайфово. Доводить - грязно, скучно и без дофамина.
Вот про это и поговорим: почему сайд-проекты мрут пачками, как выбрать тот, что доживёт, и сколько их реально тянуть одному, когда под рукой есть вайб-кодинг и три часа вечером.
Почему пет-проекты бросают на 80% готовности?
Пет-проекты бросают не в начале, а перед самым финишем - примерно на 60-80% готовности. Около 80% сайд-проектов вообще не доходят до релиза, и причина почти никогда не в плохой идее. Причина в том, что к этому моменту спадает дофамин новизны, а до первого живого пользователя ещё далеко: остаётся неинтересная возня, которую доделывать некому и незачем.
Знакомая картина? Первые выходные - огнище: скелет готов, оно уже что-то делает, ты бегаешь и всем показываешь. Через две недели надо чинить регистрацию, писать письма про сброс пароля и разбираться, почему на проде падает то, что на локалхосте работало. И вот тут рука сама тянется завести новый репозиторий. Там же снова весело.
По анализу пятидесяти заброшенных соло-проектов, который сделал Jason Jos на Indie Hackers, мотивация обваливается примерно к третьей неделе - когда пик самоуверенности прошёл, а результата ещё нет. Это не лень. Это устройство самой мотивации: она отлично работает, пока тебе интересно, и ломается ровно там, где начинается работа.
Что на самом деле убивает сайд-проекты (это не плохие идеи)
Убивает не идея, а срыв исполнения. Тот же разбор пятидесяти мёртвых проектов даёт неприятно конкретные цифры: 72% авторов вели три и больше идей одновременно и бросали текущую на 60-80% готовности ради новой. Не потому, что старая плохая - потому, что новая свежее.
Дальше - валидация, которой не было. 64% "проверяли" идею у друзей и в своих же чатиках, где все хвалят, но никто не платит. Я так делал: кидаешь ссылку в канал, тебе пишут "круто, бро", ты выдыхаешь и решаешь, что продукт нужен. А нужен он ровно нулю людей, которые готовы за него что-то отдать - деньги, время, регулярный заход. Вежливость перепутали с product-market fit.
И третье - никакой подотчётности. 90% заброшенных проектов не имели вообще никакого внешнего контроля: ни соавтора, ни созвона по пятницам, ни человека, который спросит "ну как там, выкатил?". Когда ты единственный, кто знает про дедлайн, дедлайна нет. Плюс мелочи вроде "81% не имели плана привлечения дальше лендинга и поста на Product Hunt" и "58% занижали цену из страха" - но корень один. Строить умеют все. Доводить и показывать людям - почти никто.
Как выбрать сайд-проект, который доживёт до релиза?
Доживает тот проект, у которого узкий скоуп и одна живая функция, которую можно показать чужому человеку за месяц. Не платформа, не "экосистема", не "приложение, где будет ещё вот это и вот это". Одна кнопка, которая делает одну полезную вещь, - и её видит кто-то, кто тебе не друг.
У меня это правило выстрадано. @jpgme_bot - генератор картинок, который делает ровно одно: жрёт промпт, отдаёт картинку. @joba_search_bot - парсер вакансий, который делает ровно одно: показывает, что больше половины вакансий в телеге это шум. kenku, интерактивный чарник для D&D 5e, - и тот сначала умел только держать один лист персонажа, а всё остальное я прибивал гвоздями потом. Каждый из них дожил ровно потому, что на старте я не пытался построить собор.
Практический фильтр перед стартом такой:
- Сможешь показать первую живую функцию чужому человеку за 3-4 недели? Если нет - скоуп слишком широкий, режь.
- Есть ли хоть один человек, который не ты и не твой друг, которому это надо прямо сейчас? Не "будет надо", а сейчас.
- Что именно ты выкинешь, когда времени не хватит? Если ответа нет - ты ещё не решил, что тут главное.
Вайб-кодинг тут коварно мешает: когда прототип собирается за вечер, скоуп хочется раздуть, потому что "ну оно ж быстро". Быстро собрать - не то же самое, что довести. Об этом ниже отдельно.
Сколько проектов реально тянуть одному?
Реально - один в активной фазе плюс один-два в фоне на паузе. И работает не одновременность, а разделение по времени: у каждого проекта свой блок, внутри которого больше ничего не существует. Параллельно вести пять штук в голове нельзя, а вот чередовать по расписанию - можно.
Есть ребята, которые из этого делают производственную линию. Один разработчик описал, как за 30 дней выкатил девять проектов на одном VPS без докера, держась правила "минимум два проекта в работе, паркуй, когда реально заблокирован, начинай другое, когда заскучал". Цена честная: ни один из девяти не отполирован до блеска. Но скорость обучения у него, по его же словам, в разы выше, чем была бы на одном проекте. Это осознанный размен, а не многозадачность.
Почему не больше - объясняет налог на переключение. Глория Марк из Калифорнийского университета в Ирвайне много лет изучает прерывания в работе, и её цифра из интервью: в среднем около 23 минут, чтобы полностью вернуться в задачу после одного прерывания. Американская психологическая ассоциация со ссылкой на эксперименты Мейера пишет, что переключения могут съедать до 40% продуктивного времени. Только это всё про задачи внутри одной работы. У соло-разработчика переключаешься между целыми проектами: другой стек, другая база, другие пользователи. У меня эти 23 минуты легко превращались в час.
Как я проверил это на себе: семь проектов и тупёжка
Этим летом я как раз жил в режиме "веду всё сразу". Параллельно с основной работой крутилось семь живых проектов: DnD-бот, КВН-сервис, два парсера телеграм-каналов, генератор картинок, вот этот сайт и игра в разработке. На них уходило часов по пять в день поверх рабочего.
Выгорание выглядело не так, как я ожидал. Не "лежу лицом в стену", а ноутбук открыт, я за ним сижу и даже что-то делаю. Только час уходит не на задачу, а на выбор задачи. Открыл один проект - вспомнил, что во втором висит баг. Полез в баг - вспомнил, что обещал фичу в третьем. Через час обнаруживаешь себя в четвёртом с вопросом "а зачем я сюда зашёл?". Я это назвал тупёжкой и долго засчитывал себе как "работал".
Вылечилось не таймером и не матрицей Эйзенхауэра, а скучно: я перестал делать вид, что веду семь проектов. Основной работе - фокус, петпроектам - остаток. Внутри петпроектов один активный контекст (сначала Kenku, потом игра), остальные в режиме "зашёл, починил, вышел": КВН подлатать, парсер вакансий подкрутить. Выбор из одного-двух вариантов ничего не стоит, выбор из семи стоил мне по часу в день.
Фокус - не ощущение, он виден в git. В августе я прошёлся по репозиториям и посчитал коммиты за 30 дней:
git -C <repo> log --oneline --since="2026-07-24" | wc -lВ рабочей папке 28 репозиториев, живых (с коммитами за месяц) - семь:
| Проект | Коммитов за 30 дней |
|---|---|
| DnD-бот | 444 |
| КВН-сервис | 89 |
| Конвейер статей для блога | 87 |
| Чарник Kenku | 53 |
| Этот сайт | 49 |
| Панель оплат | 29 |
| Публичный бот | 3 |
| Итого | 754 |
59% коммитов легли в один проект. В июле, когда я "вёл всё сразу", такой перекос был невозможен: всё размазывалось тонким слоем по всем семи, и не двигалось ничего. Мозг это не сервер, 16 воркеров в нём не крутится.
Отсюда два правила, которые у меня прижились. Час не можешь выбрать задачу - не ругай себя, а посчитай открытые контексты: проблема обычно в их количестве, а не в дисциплине. И следующий шаг записывай с вечера. Самое дорогое - утренний выбор "чем заняться", а если шаг записан вчерашним тобой, сегодняшний просто делает.
Почему при нескольких проектах первым замирает любимый?
Логика подсказывает, что при нехватке сил первыми отвалятся скучные проекты. У меня отвалился DnD-бот - тот, который хотелось делать больше всего и в который за месяц пришло 475 новых людей (всего в базе было 6035). Проект растёт, а разработка стоит.
Разгадка простая: любимый проект - самый сложный. Его интересные задачи требуют лучших часов головы, а их первыми съедают основная работа и переключения. На механическое (конфиг подкрутить, пожар потушить) силы остаются, на "сесть и придумать, как правильно" - нет.
И пауза не бесплатна. Ключевое отличие живого портфеля от кладбища: на кладбище проекты не на паузе, они брошены. Пауза - это когда ты знаешь, что вернёшься, и знаешь зачем. Брошенный - это когда ты уже придумал новую игрушку и втайне рад, что старую можно не трогать. Но даже честно запаркованный проект не стоит на месте: пока я не пушил DnD-бот в маркетинге, новые люди стали приходить заметно медленнее. Замороженный проект медленно едет назад. Я эту цену плачу осознанно: ничего не горит, ни один сервис не упал заброшенным, а голова снова думает, а не выбирает.
Где здесь вайб-кодинг: ускоряет стройку, но не спасает
Вайб-кодинг - это разработка, где ты формулируешь задачу словами, а код пишет модель. Он реально снимает трение на старте: прототип, который раньше был выходными, теперь вечер. Но вот чего он не делает - не чинит главную причину смерти проектов. Потерю мотивации в скучной середине он не лечит, а иногда даже усугубляет.
Логика простая и обидная. Раньше высокий порог входа сам отсеивал половину идей: если собрать прототип - это две недели, ты сто раз подумаешь, надо ли. Теперь порог упал, прототипов стало больше, а значит, больше и брошенных. Тот же дофаминовый цикл, только на стероидах: собрал за вечер, порадовался, бросил, собрал следующий. Инструмент стал быстрее - привычка бросать осталась.
При этом на доводке вайб-кодинг помогает как раз меньше всего. Сгенерировать красивый экран - легко. Разобраться, почему у конкретного пользователя не приходит письмо, дописать обработку граничных случаев, вычистить то, что модель наспамила, - тут всё равно нужен ты, руками и головой. Скучная середина остаётся скучной, кто бы ни печатал буквы.
И ещё одна ловушка, на которую я наступил сам. Большую часть кода в моих проектах пишут агенты, я подключаюсь на архитектуру и ревью. По идее это должно было разгрузить. На деле AI снял ограничение "я не успею": раньше идея нового проекта отваливалась сама, теперь руки доходят до всего. Бутылочным горлышком стал не код, а голова - решить, что делать дальше, и удержать в ней семь контекстов. Сэкономленное время очень хочется потратить на ещё один проект, так что потолок нагрузки AI поднимает, а упираешься в него всё равно ты.
Так что вайб-кодинг - это множитель. Умножает и скорость стройки, и скорость, с которой ты плодишь новое кладбище. Куда он потащит - зависит не от него, а от того, есть ли у тебя живой пользователь на том конце.
Как довести сайд-проект до живых пользователей?
Чтобы проект дожил до живых людей, нужны две скучные вещи: ранняя выкатка чужим (не друзьям) и внешняя подотчётность. Не идеальный релиз через полгода, а кривой, но настоящий выход к незнакомым людям как можно раньше - пока ты ещё на мотивации, а не после того, как она кончилась.
Ранняя выкатка чужим лечит сразу два диагноза. Во-первых, ты наконец узнаёшь, нужно ли это кому-то, кроме твоего чатика. Во-вторых, живой пользователь - это и есть новый источник дофамина вместо "начать новый проект". Один человек, который реально пользуется твоей штукой и пишет "а сделай ещё вот так", держит в проекте лучше любой силы воли. Многие проекты бросают ровно перед этим моментом - за шаг до того, как включилось сарафанное радио или подъехало SEO.
Подотчётность - это когда есть кто-то снаружи, кто спросит про результат. Соавтор, созвон, публичный лог в канале - что угодно, лишь бы не только ты знал про обещание. Я себе такой подотчётностью сделал канал: пишешь "выкачу на неделе" при трёхстах свидетелях - и уже неудобно не выкатить.
Кстати, вот этот самый блог - тоже мой сайд-проект, и живой пример темы. Это пайплайн из Claude-скиллов, который сам собирает темы, пишет черновики, гоняет их через фактчек и отдаёт мне на утверждение. Он дожил не потому, что я гений, а потому, что у него узкий скоуп (одна задача - статьи в блог), ранний выход к читателям и публичная подотчётность. На нём уже 18 живых статей - по команде python3 scripts/bp_db.py published-titles --platform sunm8 ровно восемнадцать записей. Столько же идей я в прошлой жизни похоронил бы в архиве.
Так что рецепт не про гениальность. Узкий скоуп, живой пользователь пораньше, кто-то снаружи, кто спросит. Вайб-кодинг ускорит стройку, но эти три штуки за тебя не сделает никто. А кладбище пусть остаётся - туда полезно иногда заходить и вспоминать, как это бывает, когда бросаешь на 80%.
Частые вопросы
Сколько пет-проектов можно вести одному?
Реалистично - один в активной фазе плюс один-два в фоне на паузе. Возврат в задачу после прерывания стоит около 23 минут, а между проектами с разным стеком и базой - ещё дороже. Когда я сузил фокус с семи проектов до одного, 59% коммитов за месяц легли в один репозиторий и пропал час на выбор "за что браться".
Вайб-кодинг помогает довести проект до релиза?
Он снимает трение на старте и ускоряет стройку, но не чинит главную причину смерти - потерю мотивации в скучной середине. Быстро собранный прототип так же легко бросить, если нет живых пользователей и подотчётности.
На каком этапе чаще всего бросают сайд-проект?
На 60-80% готовности, перед самым запуском - когда спадает дофамин новизны, а до фидбэка от реальных людей ещё далеко. По анализу заброшенных соло-проектов, мотивация обваливается примерно к третьей неделе.
Как готовился материал: черновик собран моим AI-конвейером по темам и заметкам из практики, факты сверены с первоисточниками, финальный текст я прочитал, поправил и утвердил перед публикацией. Обложку к статье тоже рисует нейросеть. Про сам конвейер — в разделе обо мне.
