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

Предыстория: почему я за это взялся

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

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

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

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

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

Ошибка 1: делать по остаточному принципу

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

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

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

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

Ошибка 2: делать универсальное решение

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

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

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

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

Ошибка 3: стартап за свой счет, зачем нам инвесторы

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

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

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

Ошибка 4: менять все под клиента

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

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

Ошибка 5: не начинать продажи до появления идеального продукта

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

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

Почему я не бросил

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

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

Советы

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

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