Как я делал свой первый IT стартап

Предисловие: Июль 2018 г.

Когда люди начинают общаться на разных языках это выливается в проблемы

Тогда я только закончил обучение в ВУЗе и пробовал разные проекты связанные с киберспортом, был близок к IT, но никогда серьезно там не работал. Мы с командой проводили любительские турниры под ключ, организовывали киберспортивные активности в Новосибирске, а рабочим пространством на то время была кофейня, где мы круглосуточно писали комм.преды и пытались нащупать аудиторию, которой будет интересно на регулярной основе закупать рекламные интеграции.

Акт 1: Знакомство и проблема

В очередное утро, работая в кофейне мы познакомились с моим будущим бизнес-партнером. Он оказался разработчиком и занимался аутсорсом блокчейн разработки: брал заказы в Европе\Америке и отдавал их в Индию втрое дешевле. Сам он занимался в основном код ревью и работой над своим проектом — телеграмм ботом, для обмена криптовалютами. Ему оказалась интересна идея киберспортивной лиги как инвестиционного проекта, и мы около недели обсуждали возможность реализации.

Coffee connecting people Данил Ефремов

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

В тот момент активно работали два варианта блокчейн сервисов: холодные и горячие.

Холодные сервисы

Холодные сервисы предлагали хранить публичный (адрес пользователя) и приватный ключ (пароль) на стороне клиента, и в момент необходимости подписания транзакции пользователю предлагалось ввести их собственноручно. Это было достаточно неудобно, т.к. ключи – это длинный, не связанный между собой, набор символов. Запомнить такую вереницу символов проблематично, а их введение отнимает много времени.

Горячие сервисы

Горячие сервисы предлагали создавать и содержать публичный и приватный ключи на стороне сервиса, при надобности в автоматическом режиме подписывать транзакции — операции с криптовалютами. «Горячее» хранение гораздо удобнее, но ответственность за сохранность активов остается за сервисом, что несет за собой риски потери. Например, в случае взлома данные полностью остаются у злоумышленников.

Акт 2: Решение проблемы и идея продукта

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

PWA не токо клей Данил Ефремов

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

Сравнение работы сервиса на примере интернет магазина с использованием криптовалюты
Сравнение работы сервиса на примере интернет магазина с использованием криптовалюты
Сравнение работы сервиса на примере децентрализованных приложениях.
Сравнение работы сервиса на примере децентрализованных приложениях.

Акт 3: Первые договоренности

Обсудив решение проблемы, я оставил партнера с этой идеей и продолжил работу над своим проектом. Мы часто с ним пересекались в кофейне где спокойно работали и иногда болтали. В один из дней мы решили прогуляться и он предложил работать над этим проектом вместе. Мы обсудили зоны ответственности, распределили доли 50\50 и стукнули по рукам. Распределение ответственности было примерно такое: он отвечает за разработку и продукт, я отвечаю за все остальное, с ремаркой, что решения обсуждаем и принимаем вместе.

Прогулки с незнакомцами до добра не доведут, максимум до стартапа Данил Ефремов

Акт 4: Оценка рынка и первый план, которого мы придерживались

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

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

Т.к. я был изначально далек от криптовалютного рынка мне пришлось погрузиться в изучение существующих решений. Из тех, которые существовали, удобны были единицы — расширения для браузера типа Metamask, которые по факту работали также, с внутренней памятью пользовательского устройства, но из за того, что это расширение работало только на браузере Chrome и только на стационарных устройствах мы увидели возможность отстроиться и предоставить подобный сервис для любых устройств и браузеров, которые поддерживают технологию PWA. На тот момент это было порядка 70% рынка устройств и доступных на них браузеров, против 35% у расширений для Google Chrome.

У нас был план и мы его придерживались Данил Ефремов

Акт 5: Поиск бизнес-модели

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

По нашей гипотезе сервис позволил бы существенно улучшить пользовательский опыт у проектов, которые используют блокчейн для функционирования.

Модель дистрибуции

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

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

Пользовательские сегменты

Построив такую модель в голове, мы выделили 4 сегмента с кем нам придется взаимодействовать:

  • Держатели криптовалюты

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

  • Магазины и сервисы с приемом криптовалютных платежей

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

  • Сервисы работающие на блокчейне

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

  • Криптовалюты

Работа с криптовалютами заключалась бы в размещении информации о них в приложении и возможности размещать информацию о обновлениях.

Модель монетизации

В нашей голове модель монетизации складывалась таким образом, что мы хотели брать комиссию с каждой транзакции. Т.к. на рынке не было сильных игроков, мы не понимали на что равняться и на какой процент с транзакции можно рассчитывать. Поэтому, мы сориентировались на Paypal и планировали брать 0.01-0.1% от суммы транзакции, но не менее чем 50 центов, в пересчете на доллары. Мы сильно демпанули по сравнению с предложениями фиатных валют, но в нашей голове мы были готовы смириться с этим и не жадничать для более гладкого входа на рынок.

Таблица расчетов потенциальных комиссий привязанных к географии
Таблица расчетов потенциальных комиссий привязанных к географии

Акт 6: Первая команда проекта и первые ошибки

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

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

Оценка рынка 
Оценка рынка 

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

Русские стартаперы не хотят в гараж (офис) Данил Ефремов

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

Акт 7: MVP, съезд с офиса и поиск международной команды

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

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

Демо интернет-магазин с принятием криптовалютных платежей через наш продукт

Я оформил страницы соц-сетей типа angel.co и linked.in, и начал активно искать основного по моему мнению специалиста на данном этапе — HR менеджера. Т.к. особого опыта в найме не было ни у меня ни у моего компаньона, мы решили переложить ответственность за кадры на профильного специалиста. Так же я считал важным найти специалиста по праву, который готов был бы в фоновом режиме консультировать по поводу того, где лучше зарегистрировать стартап и как защитить разработку.

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

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

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

Обсудив фронт задач с HR на ближайшее время, сошлись на том, что в первую очередь нам надо добрать бизнес девелопера (далее — BD), а я займусь первыми коммуникациями с венчурными фондами и привлечением средств.

Коперник думает о зарубежных рынках Данил Ефремов

Акт 8: Первые питчи и бизнес девелопер

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

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

У нас получились хорошие результаты с точки зрения проходимости на собеседование, проект был интересен. провели порядка 20 скайп коллов с разными фондами\бизнес ангелами и собирали с них обратную связь.

К этому моменту у нас появилось одно предложение из Сингапура. В linked.in мы познакомились с бизнесменом, который разрабатывал стартап по передаче персональных данных третьим лицам, основанный на блокчейне. В таком проекте наша система максимально гармонично встраивалась бы в пользовательский опыт. Так же у него была компания, которая занималась организацией миграции бизнеса в Сингапур.

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

  1. Усиление позиции в переговорах с инвесторами. т.к. по моему мнению вложения в работающий проект существенно снижает риски инвестора.

  2. Возможность словить волну и обойтись без инвестора, быстро нарастить оборот и выйти на рынок самостоятельно.
  3. Проект уже длился порядка 7 месяцев и по факту являлся для нас единственной занятостью. Для нас было важно получать хоть какую отдачу, т.к. ресурсы заканчивались.

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

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

В один из дней мне пришло радостное сообщение, что наша HR нашла бизнес девелопера, также из Лондона, который согласился присоединиться к команде. Мы созвонились с ним, пообщались и подумали, что он нам подойдет. У него был достаточно весомый бэкграунд, Стэнфордское образование и опыт работы с блокчейн проектами. Мы приняли решение взять его в команду и начали регулярно созваниваться по поводу развития продукта.

HR беседует с BD по Skype Данил Ефремов

Акт 9: Переговоры о пилотах и первые проблемы с бизнес девелопером

Общение с BD продолжались примерно 3-4 недели. Мы существенно улучшили бизнес-план и отработали аргументацию для инвесторов. Запустили процесс ребрендинга с нашим дизайнером. За это время я нашел несколько компаний, в основном — гемблинговые, которым было интересно наше решение, и ушел в обсуждение пилотного проекта с ними, немного отпустив работу по развитию продукта.

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

ICO тема, говорил он... Данил Ефремов

Акт 10: Полное поражение в переговорах

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

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

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

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

Акт 11: Горящие мосты

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

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

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

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

Et tu, Brute? Данил Ефремов

Эпилог

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

Долго рефлексируя над ситуацией я понял возможные камни преткновения из-за которых, по моему мнению могла случиться такая ситуация:

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

  2. Я отпустил ситуацию в момент, когда больше всего нужно было работать контактно с партнером — когда было готово MVP. По факту найденный BD завоевал влияние моего партнера, и частично забрал контроль над моими процессами. Я слишком сильно доверился опыту этого человека и лояльности моего партнера мне. В результате, у партнера сместился фокус внимания, а я не проконтролировал, что это совпадает с общими целями. Когда я обнаружил, что это произошло, ситуация уже была потеряна.
  3. Я не обезопасил себя как с технической точки зрения, так и с точки зрения юридической. Мне стоило получить доступ к репозиториям и регулярно делать бэкапы исходников. А так же, больше уделить времени регистрации юр лица и лицензионного права на использование этой разработки.

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

Вот так закончилась история с моим первым IT стартапом. Это был отличный опыт и большой потенциал у проекта. Но закончилось все гораздо прозаичнее.

4444
11
44 комментария

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

Разработчики зациклены на программных продуктах, они думают все остальное слишком несущественно и любые усилия и знания, не относящиеся к разработке, сильно уступают в значимости знаниям и навыкам, необходимым для разработки. Чего таить, я сам такой, никак не получается приравнять иные усилия моим, касающимся разработки, а надо бы. А на первых порах многие легко соглашаются на условия 50/50, потому что до реального момента, когда(и если) будет смысл что-то делить, еще очень далеко. В общем, соглашаются с мыслью "потом видно будет". Жаль, конечно, что потратили столько времени, с другой стороны ценный урок, что с самого старта вопреки советам стартап-гуру типа "оставьте юридические аспекты и тд и занимайтесь продуктом для начала" нужно все-таки закрепить свое право на продукт документально.

17
Ответить

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

2
Ответить

Интересная история.
1. Партнёр не прав что просто все забрал у тебя
2. С другой стороны, за все это время партнёр дал результат в виде мвп, а твой результат получается выразился только в том, что ты нанял кучу людей, хотя я не очень понял в чем тогда твоя роль - если это стартап мне кажется это автор должен был быть и hr и сейлзом и уборщицей и проч., а ты как бы все это делегировал и по факту результат с твоей стороны для проекта 0, а то и минус если учесть  все затраты на сотрудников - инвестиций ты не нашёл, кучу денег всадил на персонал офис секретаршу и проч. Мне кажется бизнесово партнёр прав, этически - конечно нет
3 затраты 350 тыс очень сомнительно с учётом кучи вовлечённых людей...
4. У меня нет опыта в стартапах но меня удивляет нафиг столько сотрудников нанимать открывать склад строить завод сексуальную секретаршу сейзла кадровика бизне девелопера(это кто??), охранника, специалиста по документооборота, специалиста по протоколу, офис менеджера .... а продаж 0. Ну вы поняли 😂

13
Ответить

Как очевидец происходящего в этой ситуации со стороны (да, это мой одногруппник), скажу, что этически партнер тоже был прав, ибо у стартапа не было ничего, кроме кода этого партнера. 

А еще Никитка предлагал людям "work for food" до привлечения инвестиций, которых в итоге не было. :^)

350к вероятно ушло на бензин и офис, мб на покупку печенек.

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

Никита, Даня, привет. Кофе?

Ответить

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

6
Ответить

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

6
Ответить

Комментарий недоступен

4
Ответить