Не повторяйте мои ошибки: история о том, как я много лет делал стартап на свои деньги

В 2018 году я начал развивать собственное приложение для бизнес-клубов Hubstr. Планировалось сделать его за миллион рублей и несколько месяцев. В итоге работа растянулась на годы, а косты выросли в десятки раз. Это статья о том, какие ошибки нельзя допускать, если вы ввязались в это дело.

Спойлер: сейчас проект живее всех живых!

Много лет назад я подался в предприниматели — завершил карьеру разработчика и открыл свое it-агентство. В то время мне не хватало общения с другими фаундерами — хотелось найти единомышленников и поддержку. Тогда по рекомендации товарищей я решил вступить в бизнес-клуб.

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

Какие мы поставили перед собой цели?

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

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

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

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

Если уж браться за что-то, то делать это по-максимуму! Поэтому вместо создания простого лаконичного MVP, мы замахнулись на создание универсального конструктора приложений. Идея была в том, чтобы создать аналог Тильды, при помощи которого мы смогли бы реализовывать (или значительно ускорять) создание любых других проектов.

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

Как вы понимаете, такой подход не только еще сильнее растянул разработку, но и значительно усложнил техническую составляющую. В какой-то момент показалось, что всё готово на 90%. Но вот оставшиеся 10% никак не поддавались: время шло, а вылезали всё новые и новые проблемы, вызванные универсальностью, которые приходилось решать. В итоге команда пришла к выводу, что проще и быстрее отказаться от универсальности и… сделать всё заново! Прощайте, несколько миллионов, вложенных в разработку. К счастью, это решение оказалось правильным, и новая версия была готова уже через пару месяцев и дальше дело пошло намного бодрее.

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

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

Так и появился наш Hubstr, а с ним первые продажи. И очередные проблемы, которых можно было избежать.

Один из клиентов пришел к нам и сразу попросил изменить приложение под него — предстояло сделать много-много небольших доработок. Как это обычно и бывает, требований много, а бюджет ограничен. Под такой бюджет невозможно было выделить отдельную команду, соответственно двигались мы слишком медленно. Выгорел и клиент, и команда, которая теперь металась между разработкой коробочной версии “для всех” и доработками под одного клиента.

Вывод 1: если есть отдельный продукт — формируйте под него выделенную команду.

Вывод 2: много мелких доработок под одного клиента — зло, лучше этого избегать.

Это классическая ошибка предпринимателя, о которой не сказал разве что ленивый. Но зачем учиться на чужих ошибках, если можно сделать свои? :) Хотелось реализовать как можно больше функций, все сделать идеально и только потом выводить Hubstr на рынок. В то время как правильным решением было бы сделать MVP и сразу настраивать маркетинг и продажи.

Пока вы дотачиваете до идеала, ваши конкуренты уже вовсю собирают первую прибыль.

Ответ простой — ответственность. Первые клиенты появились практически сразу, мы не могли их бросить. Предприниматели часто говорят: неважно, сколько ты потратил; важно, сколько сможешь заработать (или потерять) через месяц. Я все время думал о том, сколько уже сделано и сколько еще можно сделать. Но не буду скрывать, что иногда и я и команда очень уставали от проекта.

Сейчас у нас чуть меньше 20 постоянных клиентов и тысячи пользователей. А еще много планов по доработкам и освоению зарубежных рынков. Окупилось ли приложение? Да, и оно почти стало единорогом… но потом я проснулся!

История сослагательного наклонения не терпит, в 2007 никто не вернется. Но может мои выводы вам пригодятся:

Если хотите поближе познакомиться с Хабстером или другими моими проектами, пишите в Telegram — я всегда рад новым знакомствам и партнерствам! Кстати, подробнее о своем пути, всех ошибках и опыте я пишу в блоге - внутри полезные материалы для предпринимателей. Например, недавно составил гайд, который поможет определиться, что нужно для вашего IT-продукта: купить готовое решение или уйти в собственную разработку?