Сделал 15 ИБ-стартапов за 2 года

Меня зовут Дмитрий Беляев, я уже 11 лет в практической кибербезопасности, занимаю должность CISO в IT компании и веду канал Belyaev Security. И 2 года в вечернее время и в выходные дни я занимался стартапами и хакатонами. Мне удалось запустить больше десятка проектов (без опыта ведения своего бизнеса и опыта в разработке), и в этом помогли компетенции ИБ-специалиста и умение объединять людей вокруг себя.

В статье расскажу, что стоит учесть, если хотите запустить свой ИБ-стартап.

Как запустить проект и замотивировать 112 человек присоединиться к команде

Когда-то я был уверен, что хакатоны не для меня: «Я же не разработчик, я из ИБ, что я там забыл?». Это убеждение стоило мне нескольких лет — я просто не шёл туда, где люди делали продукты и учились запускать проекты.

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

Но именно это поражение включило азарт. Дальше был путь, который привёл к команде из 112 человек: backend, frontend, fullstack, дизайнеры, аналитики ИБ, пентестеры, маркетологи, мобильные разработчики, даже психолог и юрист. Моя роль — идеолог и организатор, человек, который собирает команду и наводит порядок.

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

Основными факторами того, что мы работали 2 года, условно, «за идею», были:

• чёткое разграничение ролей
• структура
• страховка друг друга на случай ЧП
• огонь в глазах
• вера в проекты
• вера в членов команды
• частые победы и призовые места в акселераторах и хакатонах
• мотивация в виде % от развития стартапа
• разгорающийся интерес к нашей команде.

Какие проекты мы подготовили

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

За два года мы сделали больше 15 проектов, из которых флагманскими стали несколько решений под общим кодовым названием «Kvirin»:

• Kvirin Task — мобильный задачник для Android, который должен был решить поручение и исполнение задач вовремя и из любой точки мира. Он реализован на минимальной стадии MVP-проекта.
• Kvirin DNT — расширение для браузеров, которое должно было препятствовать сбору сайтами уникальных цифровых профилей пользователей и защищать от перехода на вредоносные и фишинговые сайты. Базовая версия Kvirin DNT предназначалась для домашних пользователей и должна была обеспечивать защиту от фингерпринтинга (построения цифровых отпечатков браузера) и следящих cookie. В более продвинутой версии планировалось, что Kvirin DNT будет проверять страницы, на которые заходят пользователи, по базам Virustotal и Cisco Talos.
• Kvirin SSD — проект, представляющий собой концепцию умной SIEM-системы, в которую интегрированы OpenSource-модули СЗИ.
• Kvirin PDA — автоматизированный алгоритм обезличивания данных, работающий в веб-консоли. Проект хорошо себя зарекомендовал: он позволял загружать в веб-консоль документы формата Word и PDF, находить в них ФИО, блюрить их и собирать заново, на выходе предоставляя заказчику обезличенные документы. Демонстрация работы на Desktop-версии представлена тут.
• Kvirin UAV — проект по обнаружению нефтяных разливов с БПЛА.
• Kvirin AF — проект многомодульной защиты от фрода в финансовом секторе.
• Kvirin Anti-BEC — проект эшелонированной защиты от продвинутых BEC-атак.

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

Как всё закончилось

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

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

В какой-то момент интерес к нашим идеям и команде стал бешеным. Меня приглашали в офисы крупнейших российских ИБ-вендоров: обсуждали сотрудничество, коллаборации, варианты перехода части или всей команды в штат вендоров.

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

Я выбрал стабильность по пословице: «Лучше синица в руках, чем журавль в небе». Команда меня поддержала, а проекты ушли «в заморозку».

Этот выбор нельзя назвать ни правильным, ни ошибочным — он про личные приоритеты. Но если вы думаете о своём ИБ-стартапе, честный разговор об обременениях нужно вести до того, как вы войдёте в переговорку с инвестором или вендором.

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

Ошибки и как их избежать

«Я не разработчик, значит, стартапы не для меня»

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

Как избежать:

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

Романтизировать команду и не фиксировать договорённости

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

Как избежать:

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

Верить, что «классный проект» гарантирует победу на хакатоне

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

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

Как избежать:

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

Ждать денег акселератора и инвестора как главной цели

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

Я проходил программы ИТМО, ФРИИ, Южного ИТ-парка и могу сказать: главный актив акселерации — обратная связь, проверки гипотез и контакты, а не чек.

Как избежать:

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

Игнорировать свои обременения

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

Как избежать:

• До входа в тяжёлый стартап-путь честно ответьте себе: чем вы готовы рискнуть, а чем — нет.
• Если у вас сильные обременения, сразу ищите гибридные варианты: пилоты, консалтинг, частичную занятость, партнёрства, а не мгновенный полный переход из найма.
• Не обманывайте ни себя, ни команду обещаниями «скоро всё бросим и полетим», если в реальности это невозможно.

Недооценивать CustDev и проверку спроса

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

Хороший CustDev — это десятки живых интервью с незаинтересованными людьми из вашей ЦА, а не разговоры с друзьями и коллегами. Грамотный CustDev экономит годы холостой разработки.

Как избежать:

• Цельтесь в 50–100 живых интервью лицом к лицу с представителями вашей ЦА.
• Тщательно прорабатывайте вопросы, избавляйтесь от «наводящих» формулировок.
• Ищите не подтверждение своей идеи, а возможность её убить или скорректировать.

Лезть в гранты и обязательства без уверенности в команде

Гранты и субсидии кажутся лёгкими деньгами, но в реальности это жёсткие обязательства по срокам и результатам. Если вы не уверены, что команда вывезет, рискуете получить не развитие, а юридические проблемы и обязанность вернуть деньги.

Как избежать:

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

Советы, как выжить ИБ-стартапу

Здесь выделю ключевые вещи, которые реально помогли мне и команде.

Команда и роли

• Ищите людей на хакатонах, в специализированных чатах и комьюнити по ИБ и разработке.
• Проводите мини-собеседования, даже если это просто вступление в команду на хакатон.
• Чётко распределяйте зоны ответственности и роли, критично иметь взаимную подстраховку, если команда маленькая.

Идея, концепция и киллер-фичи

• Продукт должен иметь понятные преимущества перед аналогами, особенно в переполненной ИБ-нише.
• Сохраняйте фокус на 1–2 ключевых киллер-фичах, а не на длинном списке «когда-нибудь будет».

Архитектура и ТЗ

• Без понятной архитектуры и ТЗ вы потеряете вектор развития и скорость.
• ТЗ должно быть посильно вашей команде, иначе оно превратится в стену, о которую вы разобьётесь.

CustDev

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

Безопасная разработка и пентест

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

MVP, а не «идеальный продукт»

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

Экономика и дорожная карта

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

Акселерация

• Идите в акселераторы, если готовы работать по жёсткому графику и выполнять задания менторов.
• Считайте попадание в программу не наградой, а стартом работы.

Витрина проекта

• Сделайте сайт с описанием продукта и команды — это ваша визитка для заказчиков и инвесторов.
• Работайте с PR: публикации в профильных СМИ, выступления, подкасты, телеграм-каналы по ИБ.
• Помните, что иногда у вас есть 2–5 минут, чтобы «выстрелить», — будьте готовы презентовать проект коротко и по делу.