Ошибки соло-разработчика: что я узнал, создавая SaaS в одиночку

Почему эта статья не про успех, а про реальные грабли

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

Сбой, который научил меня, что такое бэкап на самом деле

В середине разработки моего проекта LogicFrame мой компьютер вылетел во время git commit. После перезагрузки репозиторий оказался повреждён — не «файл пропал», а «git отказывается видеть это как репозиторий». Я всегда считал GitHub абстрактным бэкапом, но никогда не проверял эту теорию. К счастью, я регулярно пушил изменения, поэтому просто склонировал репозиторий и потерял почти ничего. Урок не в том, чтобы использовать git, — я и так его использовал. Урок в том, что привычка становится страховкой только после того, как ты упал в неё и убедился, что она ловит.

Баг, который существовал только из-за моей операционной системы

Однажды деплой на Vercel провалился, и я не мог найти причину в коде. Оказалось, это была Windows-специфичная проблема: у меня были две директории: app/FinanceFriend и app/financefriend. На моей машине они были различны, но для Linux-серверов Vercel — одинаковы. Windows не различает регистр в именах папок, а Linux различает. Поэтому сборка постоянно падала. Это было унизительное напоминание: «работает на моей машине» — не шутка, а реальный баг. Когда ты работаешь один, рядом нет разработчика с другой ОС, который мог бы найти проблему.

Слияние двух кодбаз, которые не хотели объединяться

Однажды я интегрировал отдельное TypeScript React-приложение в мой основной Next.js проект на JavaScript. В теории «добавить компонент» — задача в одно предложение. На практике всё усложнилось конфликтами между Tailwind v4, различиями в области видимости CSS-переменных и циклическими импортами, которые проявились только когда кодбазы начали взаимодействовать. Ничего из этого не было сложным в смысле интеллекта. Это было сложным в смысле утомительности — когда исправляешь одну ошибку, а появляются три новые, и единственный выход — терпение, а не озарение. Соло-разработка — это в основном такое. Не архитектурные решения. А просто сидеть с проблемой, пока она действительно не решена, а не просто затихла.

Маркетинговая реальность, о которой никто не предупреждает

Я думал, что самая сложная часть запуска — код. Оказалось, нет. Я сделал LogicFrame публичным в середине июня и следующие недели пытался заставить хоть кого-то на него взглянуть: посты в LinkedIn, Reddit, группы в Facebook, отправка в каталоги, личные сообщения знакомым фрилансерам. Один пост в LinkedIn набрал пару сотен просмотров и ноль ответов. Reddit дал понять: сначала вкладывайся в сообщество, потом продвигай. Личные сообщения тоже не сработали. Группы и каталоги были той же историей: видимо, но молчаливо. За этот месяц я понял: проблема не в том, достаточно ли хорош продукт. Проблема в том, что никто не останавливается, чтобы рассмотреть что-то новое, даже люди с той же проблемой, которую он решает. Внимание по умолчанию достаётся вещам, у которых уже есть чья-то печать одобрения. Получить эту первую печать — одного реального пользователя, один честный отзыв — оказалось сложнее, чем любая задача в коде.

Что я до сих пор не решил

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

Что на самом деле значит строить в одиночку

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

Что делать прямо сейчас: если вы строите продукт в одиночку — проверьте свои бэкапы, протестируйте деплой на другой ОС, будьте готовы к утомительным слияниям и не ждите лёгкого маркетинга. И помните: каждая решённая проблема — это шаг вперёд.