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

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

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

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

При моей любви к автоматизации, сразу захотелось это исправить. Так и родилась идея сделать удобное приложение для резидентов, объединяющее в себе все ресурсы сообщества.

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

1. Улучшить клубную жизнь резидентов
2. Сделать собственный продукт, используя время от времени простаивающие ресурсы
3. Создать универсальную библиотеку компонентов на все случаи жизни (об этом ниже)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Сразу выделять отдельную команду как на полноценный коммерческий проект. Без этого не получится держать нормальный темп разработки и своевременно выпустить продукт на рынок.
2. Серьезный подход к исследованию рынка. Мы в свое время заказали исследование рынка проф. сообществ России. К сожалению, результаты исследования, говорящие о многомиллиардной ёмкости рынка, оказались не вполне точными. Поэтому даже заказные исследования лучше валидировать своими силами.
3. Не делать большие проекты за свои деньги. И не забывать о том, что помимо непосредственно разработки, нужно заложить как минимум столько же на маркетинг.
4. Развивать продукт по принципу: сначала MVP, потом контакт с рынком, потом доработки.
5. Запускать маркетинг и продажи параллельно с разработкой.