IT cтартап в одиночку или небольшой командой - ожидание и реальность. Ошибки, которые не надо повторять.

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

Привет. У меня есть за плечами 2 некоммерческих успешных проекта с общей активной аудиторией более 35к пользователей в неделю. Это расширения для браузера для отслеживания времени и расширение с отключением отвлекающих элементов на YouTube. Но этого конечно же мало и хочется тешить свое самолюбие не только активной аудиторией и полезным продуктом, но и регулярными входящими платежами на счет.

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

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

Приступив к реализации продукта, я построил архитектуру проекта, структуру баз и сервисов. Старался выбирать наиболее оптимальные технологии для текущей задачи и в итоге пришел к выводу использовать несколько новых для себя технологий. Это комбинация имеющегося опыта (и его отсутствия в некоторых областях) и рьяного желания использовать “самую подходящую“ технологию для поставленной задачи. Это была ошибка номер 2.

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

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

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

Важно концентрироваться на MVP, на той фиче продукта, вокруг которой уже будет обрастать весь остальной функционал. Ошибка номер 4 - концентрироваться не на MVP.

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

Я считаю, что допиливать первую версию до идеала - это ошибка номер 5.

Но когда мы пишем стартап, который решает одну маленькую проблему, в которой мы до конца не уверены, нужно делать все как можно скорее.

Что в итоге?

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

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

Что забыли сделать после запуска?

Вот наконец продукт написан и готов к запуску. Вроде вот-вот будет заветный релиз и можно почивать на лаврах? Ага, только еще осталась “самая малость” - рассказать о своем продукте. И в этот момент мы понимает, что разработка, это только 50% всех трудозатрат. Да не, не может быть!

И после этого мы погружаемся в дебри маркетинга, рекламы, seo. Хотя это уже совсем другая история.

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

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