Как довести пет-проект до релиза

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

Причины

1. Не хватает времени

Многие скажут, что времени не хватает. Проблема нехватки времени всегда была и всегда будет у человечества. Это довольно философский вопрос: «Где взять больше времени?». О том, как экономить время, есть прекрасная книга Максима Дорофеева «Джедайские техники». Если кратко: чтобы все успевать, нужно экономить не время, а мыслетопливо, которое требуется для выполнения сложных и нетривиальных задач. Что такое мыслетопливо и как с ним работать, подробнее разобрано в книге.

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

2. Непонятно, как вывести в продакшн

Многие разработчики в первую очередь бросаются кодить, но не думают о дистрибуции своего продукта. В результате об их пет-проектах узнают только те, кто зайдет в их аккаунт на GitHub. Что с этим делать? Настраивать пайплайн релиза в первую очередь.

Написали Hello World - сразу настройте пайплайн релиза. Для простого веб-сайта подойдет GitHub Pages. Если сайт сложнее, настройте деплой на DigitalOcean или другую платформу. Если речь о мобильном приложении, настройте публикацию в TestFlight. Разрабатываете десктопные приложения - заранее изучите инструменты выпуска новых версий и обновлений, пока приложение не обросло кучей других фич.

Почему это важно? С самого начала вы решите проблемы разных версий и разных окружений, под которые нужны разные секреты и переменные:

• Вы настраиваете пайплайн так, чтобы секреты подставлялись автоматически, и продумываете защиту веб-сайта от утечки секретов в публичный доступ.
• Вы продумываете, как не включать логи Google Analytics в версии приложения, которые запускаются на вашем смартфоне в Xcode или на localhost.
• Вы настраиваете сервер, DNS и Let’s Encrypt.

Даже если вы пока не знаете всех этих процессов, вы изучите много нового для себя. Эти знания останутся с вами, даже если пет-проект не будет завершен. Знания никогда не бывают лишними. Час настройки пайплайна деплоя в начале сэкономит неделю исправлений в конце.

3. Нужно много ресурсов

У меня есть пет-проект techinterview.space, который я развернул на DigitalOcean. Только на инфраструктуру уходит чуть больше $50 в месяц: VPS, PostgreSQL, S3. Помимо этого, были расходы на услуги дизайнера: разработка маскота и стикеров в Telegram обошлась почти в $600. Все это - для развития моего личного бренда за счет предоставления сервиса с полезной статистикой пользователям. Не каждый готов расстаться с такой суммой, а потому рекомендую начинать с самых дешевых или бесплатных решений: GitHub Pages для деплоя, бесплатный план на 100 писем в сутки от Resend.com, бесплатный тариф от Auth0 для авторизации и т.д.

Если ваш пет-проект - это мобильное или десктопное приложение, то с ним даже проще. Выпущенное приложение живет само по себе, не требуя постоянного внимания, затрат и усилий, в отличие от веб-сайтов. У меня сейчас, помимо techinterview, есть два приложения для iOS (на момент 2026-02-19), набор фич в них уже устоялся, и они не находятся в стадии активной разработки.

Еще одна мысль, о которой не каждый задумывается на старте разработки: каковы условия его закрытия? Задайте себе вопрос: «Как я пойму, что пора остановиться, и что я буду делать, когда так решу?». В случае мобильных приложений мне ничего делать не нужно, ведь я могу просто перестать платить подписку на Apple Developer и не выпускать новые версии, но в случае techinterview план такой:

1. Объявляю на главной странице и ключевых страницах притяжения, что проект на стадии завершения.
2. Отключаю бэкенд. Новые анкеты и отзывы о компаниях приниматься не будут.
3. Делаю сайт статичным. Все данные, собранные на момент закрытия, будут сохранены в JSON-файлы и просто рендериться на сайте. Теперь нет фронтенда и бэкенда - есть только статичный сайт, фиксирующий состояние рынка на определенный момент времени.

В таком статичном состоянии я планирую держать сайт еще полгода. После этого проект останется в виде набора данных в репозитории GitHub. Разработав такой план, я «разрешаю» себе перестать тратить время, усилия и ресурсы на проект. Закрытие проекта - это нормально. Определите для себя план действий и критерии завершения, и тогда вы будете знать ответ на вопрос: «А вдруг не получится?».

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

4. Продукт пишется не для себя

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

1. А применяемые мной паттерны - точно самые эффективные?
2. Не лечу ли я симптомы вместо того, чтобы решать корень проблемы?
3. Сколько еще есть способов решить мою задачу? Есть ли способы эффективнее?

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

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

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

EV Charge Tracker

Я люблю вести учет чего-либо. Когда я только начал водить авто в 2014 году, я стал вести записи заправок и трат в приложении. В 2025 году я пересел на электромобиль и увидел, что приложений для учета трат на электрические автомобили не так много: вместо заправки топливом теперь нужно записывать сессии зарядки и потребленные киловатты. Оказалось, что выбор небольшой среди бесплатных решений, и даже они не дают нужного мне набора фич. Так я и решил написать свое собственное приложение EV Charge Tracker. Судя по аналитике, не я один столкнулся с потребностью вести такой учет, но об этом ниже.

Journal Wallet

Летом 2025 года я планировал поездку для троих человек в Европу, и мне нужно было собрать очень много документов на визы, купить билеты на перелеты и забронировать отели в разных городах. Все эти данные в итоге оказались разбросаны по разным местам: что-то в Notion, что-то в почте, что-то - в виде фотографий в телефоне. Так мне пришла идея написать приложение для планирования путешествий Journal Wallet, которое позволило бы хранить все, что относится к одной поездке, в одном месте.

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

5. Пропадает мотивация, когда непонятно, кто еще пользуется продуктом

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

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

Если вы еще не сталкивались с интеграцией аналитики, то Google Analytics уже из коробки дает много полезной информации: сколько активных пользователей, какова длительность сеанса взаимодействия, какие события были залогированы. Для моих проектов статистика следующая за последние 30 дней (на момент 2026-02-19):

Приятным удивлением были сообщения пользователей приложения для автомобилей. Люди просили добавить их валюту, делились багами и просили добавить фичи, так как их паттерны зарядок отличались от моих. Самый забавный случай: кто-то из Турции просто прислал мне в Telegram файл локализации с переводом на турецкий язык без какого-либо контекста и других сообщений. То есть он перешел в GitHub-репозиторий приложения, скачал оттуда существующий файл локализации, перевел все на турецкий и затем отправил мне. Так появился турецкий язык в моем приложении. Дайте пользователям легкий способ связаться с вами. На сайте и в мобильных приложениях я оставляю ссылку на свой аккаунт в Telegram.

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

Заключение

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

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