Кладбище пет-проектов: типичные ошибки разработчиков на пути к собственному продукту

Эх, сколько планировщиков и туду-листов так и не увидел мир.

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

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

Поэтому все грабли, которые будут в этой статье, я испытывал на собственной шкуре. Давайте разбираться, как не пополнить домашнее кладбище очередным мертворождённым продуктом.

Сейчас будет больно. Разработка — это только 10% от остального

Пора принять факт, что разработка продукта сегодня почти ничего не стоит. Особенно с развитием ИИ. Собрать первую базовую MVP-версию теперь может любой разработчик. Если раньше для этого ещё нужна была минимальная команда — один бэкенд, один фронтенд, может быть дизайнер, — то сейчас фронтенд-разработчик с лёгкостью сможет собрать бэкенд на коленках с помощью AI. А бэкенд-разработчик соберёт базовый фронтенд без знания вёрстки и даже без дизайна — достаточно просто кинуть референс нейронке или взять Tailwind.

Такие продукты сейчас есть у каждого второго разработчика. Основная проблема — что делать дальше, когда у тебя уже есть продукт. Это как минимум нужно понимать и не строить иллюзий. Не надо растягивать эти 10% на целый год, потому что потом будет очень больно. Сразу готовьтесь к длинной дороге, которая начинается в остальных 90%. А там и сбор обратной связи, и продвижение, и маркетинг, и поиск product market fit, и монетизация, и креативы — и так далее, и так далее.

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

Архитектура и выбор идеальных инструментов только отдалит вас от цели

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

Я смотрел видео разработчика, который запускал свой продукт. Он выбирал стек для мобильного приложения между Swift и React Native и решил делать на Swift, потому что «приложение будет весить на несколько мегабайт меньше». Кто из пользователей вообще смотрит на вес приложения? Если оно весит 20 МБ, его скачивают, а если 30 МБ — уже нет? Путь от инженерного мышления к бизнес-мышлению обычно долгий. Кажется, что нужны годы, чтобы перестать оптимизировать то, что пользователю не даёт никакой реальной ценности. А что произойдёт, если ему понадобится Android-версия? Он потом же вбухает несколько месяцев разработки просто впустую. Если бы выбрал RN, то выкатил бы сразу обе платформы одновременно. Поэтому как минимум нужно отталкиваться от финальной цели, а не от сиюминутной оптимизации.

Инструменты нужно выбирать по простому принципу: на чём сделать быстрее, что я знаю лучше всего и что самое популярное на рынке. Поэтому чаще всего для мобильного приложения это будет React Native + Expo, а для веба — Next.js или React + Vite и вся обвязка вокруг этого. Деплоить можно через Vercel — там же можно на коленках быстро собрать простой бэкенд на Node.js и задеплоить его за пару минут. Либо сделать более серьёзный бэкенд с базой данных с использованием Firebase или Supabase. Всё.

А чаще всего бэкенд вообще не нужен для старта. В моём текущем мобильном приложении бэкенд используется только для проксирования AI-запросов к OpenRouter. А все данные хранятся на устройстве в локальной базе данных. Если появится потребность в отдельном бэкенде и внешней базе, это всегда можно будет сделать позже.

Нужно выбирать идею, которая зажигает. Топлива должно хватить на длинную дистанцию

Если открыть любой ролик на YouTube на эту тему, то можно услышать примерно такой булшит из книг про создание компаний на миллиард:

Выйдите на улицу и спросите у 100 людей, какие у них есть боли.

Спросите пользователей существующих продуктов, какие у них есть боли при использовании приложения Y.

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

Рациональный сухой выбор на основе метрик подойдёт только инвесторам или людям с деньгами, которые просто запускают десятые бизнесы. Они выберут нишу, которая выстрелит с максимальной вероятностью, наберут под это команду, закинут кэш и пойдут курить бамбук. Но это вариант не для нас, если мы планируем делать всё сами, без инвестиций и большой команды.

Брать незнакомую доменную область — это плохая идея

Если вы хотите сделать приложение для фитнеса, но сами последний раз занимались чем-то похожим на уроке физкультуры в школе, — это плохая идея.

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

Я довольно глубоко погружён в тему изучения языков, поэтому решил зайти именно в эту сферу. Это и моя боль, и моя сильная сторона — я знаю все типы приложений на рынке, понимаю, как работают частные преподаватели, как проходит обучение в группах или персонально, знаю лидеров рынка в этой теме. В итоге мне не нужно было тратить время на ресерч — я просто взял конкретную проблему и начал её закрывать.

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

Притягивание проблемы за уши. Когда мы делаем просто чтобы сделать что-то

Очень вероятно, вы сейчас узнаете себя. Когда я делал приложение для ведения расходов, у меня на самом деле не было проблемы с тем, что нет приложений для этой цели — их было полно. Я просто не мог себе признаться, что хочу запилить какое-то приложение, чтобы освоить определённый стек. В то время я хотел изучить React Native и Node.js на бэкенде. Это было ещё пять лет назад: я работал в Сбере и думал о разработке исключительно как о карьерном росте. Поэтому это частая проблема джунов и мидлов, когда они начинают что-то делать.

Я, конечно, пытался придумать проблему: мол, остальные приложения неудобные, я сделаю лучше — не знаю как и чем, но обязательно сделаю лучше.

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

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

«Хороший продукт продвигает себя сам» — АХАХАХ, нет

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

Маркетинг будет очень дорогим. Найти такую дыру, где закидываешь 1000 рублей в маркетинг, а получаешь продаж на 2000 рублей, практически невозможно. Если вдруг получится так сделать — вы сразу миллионер. Поэтому вас ждёт кровавый мир креативов, продвижения и привлечения внимания к своему продукту любой ценой.

«Сейчас вот только доделаю вот это и то, и ещё баги пофикшу, чтобы сырой продукт не показывать»

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

Нужно сделать буквально одну фичу — самую главную, а всё остальное убрать.

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

В общем, нужно просто делать минимум и сразу показывать продукт, собирая обратную связь. Это поможет двигаться в правильную сторону и дальше строить планы. Без этого никак не получится. Невозможно сидеть и строить несколько лет «идеальный продукт», а потом в один день всех удивить. Это заблуждение — так не бывает.

Продукт будет строиться органически, постепенно собирая фидбек. Когда я выкатил приложение для изучения языков, то быстро понял по отзывам самые главные проблемы. Например, пользователь попадал на пустой экран, где у него 0 слов и было непонятно, что делать. После этого я добавил на стартовый экран кнопку «добавить 5 слов», чтобы пользователь мог быстро начать и понять механику. Затем появились другие комментарии, и я начал постепенно закрывать самые частые проблемы. При этом в моей голове изначально были совсем другие приоритеты — я даже не мог догадаться, что реально будет волновать пользователей. Это чистая органика, и здесь нет никакой схемы. Единственная схема — отдать свой продукт пользователям и наблюдать, что будет происходить.

Уже на старте нет понимания, как продукт будет зарабатывать

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

Какие могут быть примеры. Недавно видел ребят на Product Radar, которые сделали клон Perplexity, только бесплатный. Да, просто под капотом ходят в сторонние модели и выдают результат. Сами платят за токены, а пользователи пользуются бесплатно. Сразу пошёл поток пользователей, но как на этом зарабатывать — непонятно.

Или какие-нибудь сервисы, куда приходят за быстрым результатом. Например, нужно быстро что-то найти в вебе: «онлайн-конвертер формата видео» или «обрезать фон у изображения». Это, по сути, разовые действия — там может быть много пользователей за счёт хорошего SEO, но это мёртвые идеи с точки зрения монетизации. Людям нужно получить быстрый результат раз в год и забыть про сервис. Если перед скачиванием результата будет paywall-экран, пользователь со 100% вероятностью закроет сайт и пойдёт по следующей ссылке в выдаче.

В своём текущем приложении я выкатил Pro-подписку сразу на этапе MVP. И хотя бы какая-то концепция будущей бизнес-модели была изначально. Есть бесплатное приложение с определёнными лимитами, но таким образом, чтобы им можно было пользоваться. А есть Pro-подписка без лимитов и в будущем — с дополнительными фичами. И уже сейчас я понимаю, что Pro-подписку оформляет примерно 1% пользователей, и я могу отталкиваться от этого при дальнейшем развитии продукта.

Не надо тратить деньги, особенно если они не бесконечные

Когда я делал сервис для менторства, который умер, так и не родившись (вот здесь статья на эту тему), я изначально был убеждён, что нужно делегировать всё, что я плохо знаю, на сторону. В итоге за полгода я потратил 400 000 рублей на дизайн и бэкенд, а фронт делал сам. И когда пришла пора показывать MVP, я понял, что сделал вообще не то, что нужно людям. Меня сильно выбила из равновесия ситуация, когда стало ясно, что фидбэк очень плохой. А то, что я потратил деньги, добило ещё больше. Я понимал, что, чтобы двигаться дальше, нужно будет снова вкладываться, поэтому мотивация быстро закончилась, и я решил не продолжать.

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

Если не получается всё делать самому, то лучше найти партнёра с нужными компетенциями, который разделит интерес к вашей идее. И сразу заключить формальный договор, что вы будете делить прибыль 50/50, когда она появится. А если и потребуется вкладывать небольшие деньги на эксперименты с маркетингом или инфраструктурные расходы, их можно будет также делить 50/50 или, например, записывать расходы и в будущем из первой прибыли компенсировать их в приоритете до делёжки.

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

Пишите в комментариях, почему вы забросили свои проекты, и кидайте ссылки на сами проекты, если они ещё живы — всем будет интересно посмотреть.