Пет-проекты: как делать их правильно и не выгорать

У меня было много пет-проектов. И почти ни один из них не дошёл до продакшена. Это нормальная история, хотя на старте кажется, что ты просто "не дожал". Обычно всё начинается одинаково. Ты хочешь прокачаться, придумываешь проект и сразу думаешь в категориях продукта: сделаю сервис, запущу портал, буду зарабатывать. Я тоже через это проходил. Пытался одновременно писать код, делать контент, продвигать В какой-то момент стало понятно, это не разработка. Это отдельный бизнес. И это совсем другая сложность.

И вот здесь важный перелом. Пет-проект это не стартап. Это тренажёр. Если ты путаешь эти вещи, ты выгоришь. Почему большинство пет-проектов не доходят до конца? Потому что слишком большой scope, нет чёткой цели, смешивается с основной работой, ожидания "это должно выстрелить". В итоге нет результата, падает мотивация, проект забрасывается, и кажется, что проблема в тебе. Но проблема изначально была в подходе.

Как это выглядит у меня сейчас. Раньше я делал пет-проекты как попытку сделать продукт. Сейчас как лабораторию. Например: попробовать новый фреймворк (Laravel, Symfony), протестировать архитектуру (DDD, агрегаты, границы), проверить техническое решение. Это уже не "делаю сервис". Это "проверяю гипотезу".

Первое правило: не делай большой проект. Не клон Uber, не маркетплейс, не стартап. Сделай один ограниченный модуль, например импорт CSV с валидацией, отчётность, интеграция с внешним API, система ролей. То, что реально встречается в работе.

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

Третье правило: используй пет как лабораторию архитектуры. Это лучшее место, чтобы попробовать DDD, поиграть с границами, протестировать структуру. Потому что ты не рискуешь продакшеном, можешь ошибаться, можешь переделывать. Но самое важное это возможность проверять технические гипотезы. Например, у нас была ситуация: мы понимали, что в Laravel значительная часть времени уходит на bootstrap. И появилась идея — попробовать заменить встроенный DI-контейнер на более быстрый, например PHP-DI. По бенчмаркам он выглядел быстрее. Но бенчмарки — это не система. Вопрос был в другом: насколько сложно внедрить, как это повлияет на текущий код, не сломает ли это архитектуру. Такие вещи нельзя тестировать на продакшене. И вот здесь пет-проект идеальная среда. Ты можешь поднять изолированный проект, внедрить библиотеку, проверить интеграцию, понять реальную сложность, и только после этого принимать решение. Пет-проект в этом случае это не "поиграться", а инженерный полигон.

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

Но как инструмент развития это один из лучших форматов. Потому что ты расширяешь стек, тестируешь подходы и набираешься практики. С опытом меняется и качество. Раньше мои проекты были без инфраструктуры, без CI/CD, просто код на сервере. Сейчас, например, CI/CD, нормальный деплой, инфраструктура, инструменты качества. Это уже отражение накопленного опыта. И это ещё один важный момент. Пет-проекты показывают твой рост. Если через год ты делаешь их так же, ты не растёшь. Если меняется подход, структура, инструменты, значит всё идёт правильно.

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