Пет-проект становится товаром не после логотипа и не после загрузки архива на площадку. Сначала нужно доказать, что знакомая вам проблема повторяется у других, затем убрать из проекта всё личное и сделать результат воспроизводимым: понятный запуск, демо, скриншоты, лицензия, цена и правила обновлений. Продавать можно исходники разово или доступ по подписке, но формат должен соответствовать тому, что вы реально готовы поддерживать. Vibedepot здесь работает как инфраструктура сделки: карточка, премодерация, оплата и выдача. Спрос, качество продукта и обещания покупателю остаются ответственностью автора.
Сначала найдите повторяющуюся боль
У хорошего пет-проекта обычно есть сильное начало: автору надоело делать что-то вручную. Он собрал планировщик для своей команды, скрипт для регулярной рассылки или сервис, который считает нужные показатели. Это лучше абстрактной идеи, потому что продукт уже встречался с реальной задачей.
Именно такой софт в первой статье о Vibedepot назван третьим жанром: не заказная разработка и не бизнес целиком, а готовое решение, которое можно передать другому человеку. Если проект появился из диалога с AI, путь до рабочего продукта подробнее разобран в статье о вайбкодинге.
Но личная полезность ещё не доказывает рынок. Спрос появляется, когда совпадают три вещи:
другие люди узнают в описании свою ситуацию;
они уже тратят на неё время, деньги или внимание;
ваш проект можно перенести из личного окружения без полной пересборки.
Сформулируйте ценность без названия и стека: «помогает небольшой команде вести задачи на своём сервере» понятнее, чем «мой React-проект с красивым канбаном». Затем найдите людей, которые живут в таком контексте. Не спрашивайте, нравится ли идея. Спросите, как они решают задачу сейчас, что в этом раздражает и за что уже платят.
Товар начинается в тот момент, когда чужой человек узнаёт свою проблему раньше, чем замечает ваш стек.
Проверьте спрос до упаковки
Необязательно сначала доводить проект до блеска. Сделайте короткое описание, покажите рабочий сценарий и предложите человеку пройти его самостоятельно. Самые полезные сигналы не комплименты, а действия: пользователь просит доступ, возвращается второй раз, задаёт вопрос о переносе данных, уточняет цену или готов заплатить за текущую версию.
Минимальная проверка может выглядеть так:
Найдите несколько людей с одинаковой задачей, но не из круга друзей-разработчиков.
Покажите один законченный сценарий, а не экскурсию по всем функциям.
Дайте тестовую копию или проведите короткое демо без подсказок.
Запишите места, где человек остановился, и вопросы, которые повторились.
Назовите предполагаемую цену и спросите не «нормально ли», а готов ли человек купить в таком виде.
Отказ тоже даёт данные. «Не нужно» говорит о слабой боли. «Нужен импорт из таблицы» указывает на барьер перехода. «Напишите, когда будет инструкция» означает, что ценность видна, но поставка пока вызывает тревогу. Упаковывать стоит не все пожелания, а то, без чего покупатель не может получить обещанный результат.
Соберите минимальную поставку
Покупатель получает не вашу память о проекте, а файлы. Если для запуска нужно написать автору пять сообщений, перед ним ещё не товар. Минимальная поставка должна пережить чистый компьютер и человека, который впервые видит репозиторий.
Проверьте архив по списку:
исходный код или другой заявленный результат;
манифест запуска:
package.json,requirements.txt,Dockerfileилиcompose;lock-файл для воспроизводимой установки;
.env.exampleсо всеми переменными и безопасными примерами;команды установки, миграций, запуска и сборки;
лицензия и ограничения использования;
короткий раздел с типичными ошибками;
версия продукта и журнал изменений.
README.md отвечает на вопрос «что это за проект и как он устроен». start_here.md ведёт покупателя от распаковки до первого работающего экрана. Для небольшого продукта достаточно одного хорошо написанного файла; два полезны, когда обзор и операционная инструкция заметно отличаются.
В документации Vibedepot эти элементы собраны в проверку готовности проекта. Там же зафиксирован правильный порядок для покупателя: сначала прочитать start_here.md или README.md, затем запускать код. Это не формальность. Инструкция уменьшает число одинаковых вопросов и показывает, где заканчивается комплект, а где начинается отдельная настройка.
Покажите продукт, а не обещание
Демо нужно не каждому проекту, но доказательство работы нужно всегда. Для веб-приложения лучше дать рабочий пример с тестовыми данными. Для скрипта подойдёт короткая запись полного прохода. Для шаблона важны несколько экранов в реальном размере и фрагмент результата после настройки.
Скриншоты должны отвечать на вопросы покупателя:
что он увидит после запуска;
как выглядит основной сценарий;
где происходит ключевой результат;
какие есть настройки или административная часть;
как продукт ведёт себя на целевом устройстве.
В форме продажи продукта на Vibedepot можно загрузить до шести изображений, первое становится обложкой, а ссылка на демо остаётся необязательной. Не тратьте галерею на шесть вариантов главного экрана. Покажите путь: вход, действие, результат, управление. Замажьте почту, токены, имена клиентов и любые реальные данные.
Выберите цену и формат продажи
Цена не обязана возвращать все часы разработки. Покупатель сравнивает её со стоимостью альтернативы: ручной работой, подпиской на другой сервис, заказной разработкой и временем на самостоятельную сборку. Чем уже и яснее результат, тем легче объяснить цену.
Разовая покупка подходит, когда человек получает законченную копию: исходники, шаблон, скрипт или набор файлов. На Vibedepot такой товар выдаётся ZIP-архивом после подтверждённой оплаты. Сразу укажите, что входит в цену: текущая версия, будущие обновления, помощь с запуском, допустимое число проектов или пользователей.
Подписка рациональна, если ценность продолжается после установки: работает размещённый сервис, обновляются данные, поддерживается инфраструктура или регулярно выходит содержимое. На Vibedepot подписчику выдаётся персональный ключ на 30 дней; покупатель продлевает доступ вручную, а продукт проверяет ключ через API. Не выбирайте подписку только ради регулярной выручки. Если после покупки вы ничего регулярно не предоставляете, человеку будет трудно понять, за что платить снова.
Оба формата можно включить одновременно, когда предложения действительно различаются: например, исходники для самостоятельного развёртывания и доступ к обслуживаемой версии. Описание должно разводить их без мелкого шрифта.
Проверьте лицензии и удалите секреты
Работающий архив может быть непригоден к продаже, если в нём лежат чужие права или ваши доступы. Перед упаковкой проверьте лицензии зависимостей, иконок, шрифтов, фотографий, демоданных и фрагментов кода. Разрешение использовать компонент в проекте не всегда означает право перепродавать его отдельной частью набора.
Добавьте собственную лицензию, где прямо сказано, что получает покупатель: право изменять код, использовать в коммерческом проекте, делать клиентские внедрения или только запускать одну копию. Отдельно обозначьте запрет на перепродажу архива как есть, если он вам нужен. При сомнениях в совместимости лицензий лучше получить юридическую консультацию, чем прятать вопрос в FAQ.
Перед релизом найдите и удалите:
.envи локальные конфиги с реальными значениями;API-ключи, токены ботов, пароли и приватные ключи;
дампы базы с персональными данными;
адреса внутренних серверов и тестовые аккаунты;
закрытые документы, логи и пользовательские загрузки.
Замените секреты на названия переменных в .env.example и объясните, где покупатель получает собственные значения. По оферте для вайбкодеров автор отвечает за законность содержимого, отсутствие вредоносного кода, соблюдение сторонних лицензий и соответствие карточки реальному продукту.
Отнеситесь к премодерации как к релизу
Каждый продукт на Vibedepot проходит премодерацию и появляется в каталоге после одобрения. Для разовой продажи нужен рабочий файл проекта; карточка должна честно описывать поставку, а в архиве должна быть инструкция запуска с переменными окружения. Поэтому кнопка «Отправить на проверку» полезна как жёсткая граница версии: к этому моменту название, обещание, файлы и изображения должны говорить одно и то же.
Перед отправкой пройдите путь покупателя на чистом окружении:
Скачайте финальный ZIP, а не рабочую папку.
Следуйте только собственной инструкции.
Используйте новый
.env, пустую базу и обычную учётную запись.Проверьте основной сценарий и ожидаемые ошибки.
Сверьте карточку со списком файлов и фактическими функциями.
После публикации контентные изменения карточки снова отправляют её на проверку: до одобрения товар исчезает из каталога, но уже выданные доступы сохраняются. Новый ZIP начинает выдаваться прежним покупателям только после одобрения модератором. Это защищает поставку, но требует планировать обновление как релиз, а не заменять архив на ходу.
Выпускайте обновления и ищите первые продажи
Обновление должно отвечать на три вопроса: что изменилось, нужно ли переносить данные и как откатиться. Держите версию в архиве, добавляйте CHANGELOG, описывайте миграции и не ломайте старую конфигурацию молча. Если обещаете обновления в карточке, уточните их формат. «Все будущие версии навсегда» звучит щедро, но быстро превращается в бессрочное обязательство.
Первые продажи редко приходят от одного факта публикации. Начните с места, где вы нашли проблему: профессионального чата, сообщества, коллег по отрасли или людей, участвовавших в тесте. Покажите не каталог функций, а короткую связку «было действие вручную, теперь результат получается так». Ведите заинтересованного человека на карточку, где он сможет сверить комплект и условия покупки.
После запуска смотрите не только на оплату. Просмотры без вопросов могут означать слабое обещание. Вопросы без покупки часто показывают недостающую инструкцию, непонятную лицензию или высокий риск запуска. Первая обратная связь нужна для доработки карточки и поставки, а не для срочного добавления десяти функций.
Полезный цикл выглядит просто: показать, услышать возражение, исправить упаковку, выпустить понятное обновление и снова показать тем, кому эта проблема уже знакома. Так пет-проект постепенно становится продуктом, не притворяясь большим бизнесом раньше времени.
FAQ: продажа пет-проекта
Как понять, что пет-проект кому-то нужен?
Ищите действия: люди просят доступ, пробуют основной сценарий, возвращаются, спрашивают о переносе данных и готовы обсуждать цену. Одних похвал недостаточно.
Что обязательно положить в архив?
Заявленный результат, файлы запуска, lock-файл, .env.example, инструкцию README.md или start_here.md, лицензию и безопасные примеры без секретов.
Нужно ли делать демо?
Для веб-продукта желательно. Если публичное демо невозможно, покажите полный сценарий на видео или последовательных скриншотах и честно объясните ограничения.
Что выбрать: разовую покупку или подписку?
Разовую покупку выбирают для законченной копии или исходников. Подписка уместна, когда автор продолжает предоставлять сервис, данные, инфраструктуру или регулярные обновления.
Можно ли продавать проект на open source?
Иногда да, если лицензии всех компонентов разрешают выбранную модель использования и вы соблюдаете их условия. Проверять нужно не только основной репозиторий, но и ассеты, данные и зависимости.