Я никогда раньше не участвовал в хакатоне как участник челленджа. Хотел попробовать, хотел собрать команду. Команду собрать не вышло. В итоге сутки я работал один и сдал продукт для венчурных фондов в нише, с которой до этого не пересекался ни дня.
Ниже: как это выглядело изнутри, что реально построилось, чем пришлось платить и что из этого стоит забрать себе, если вы тоже собираетесь строить что-то в одиночку.
Как я туда попал
Про Hack-Nation 6th Global AI Hackathon мне рассказала знакомая. Хакатон проводится при MIT Club of Northern California и MIT Club of Germany: 5500 заявок, участники из 125 стран, представители 600+ университетов, больше 2000 человек на старте. Шесть челленджей от спонсоров, 24 часа на прототип, призовой фонд от $35 000 плюс API-кредиты.
План был простой: идём вдвоём, добираем ещё пару человек, делаем нормальную команду. План развалился на регистрации. Ей просто не дошло письмо-приглашение с кодом доступа, а без кода на платформу не попасть. Проблема оказалась массовой: в Discord несколько человек репортили то же самое. Организаторы решают такие случаи вручную, и до старта её вопрос не решился.
Дальше я искал команду сам, в Discord-канале челленджа. Там всё это время шла живая ярмарка: люди кидали интро, ссылки на LinkedIn, звали к себе. Полтора десятка команд заявились на мой челлендж ещё до старта. Я в итоге остался соло.
Забегая вперёд: соло на этом хакатоне оказалось не таким уж редким выбором.
Челлендж: The VC Brain
Второй челлендж, спонсор Maschmeyer Group. Формулировка: построить AI-first операционную систему для венчурного фонда, которая позволяет принять обоснованное решение по чеку $100K за 24 часа вместо нескольких недель.
Задача звучит как «ещё один скрининг стартапов», но вся суть в деталях брифа.
Проблема, которую спонсор описывает так: лучшие фаундеры часто не получают денег не потому, что идея слабая, а потому что никто с чековой книжкой про них не знает. Их история размазана по питч-декам, репозиториям, недоделанным сайтам и постам, которые никто внимательно не читает. Классический дью-дилидженс это недели звонков и рекомендаций: экономика, которая не сходится на чеке в $100 000. Капитал течёт по связям, а не по заслугам. А ранние команды невидимы для существующих венчурных инструментов, потому что их ещё нет ни в Crunchbase, ни в Dealroom.
Отсюда самая сложная и самая ценная часть задачи: как оценить фаундера, у которого ещё нет трек-рекорда. Не отфильтровать, а именно оценить.
Рубрика судейства расставляла приоритеты явно: архитектура данных и интеллект системы 30%, польза для инвестора и исполнение 30%, качество анализа и доверие 25%, интерфейс 15%. То есть красивый интерфейс поверх посредственных данных проигрывает.
Как разобраться в незнакомой нише за сутки
Это, пожалуй, самая полезная часть опыта, потому что она переносится на любую задачу.
Венчур я знал на уровне общей эрудиции. Ни одного дня практики. Сутки на то, чтобы понять предметку глубже, чем поймут те, кто просто прочитал бриф.
Что сработало.
Первоисточник важнее пересказа. У челленджа была сессия вопросов и ответов со спонсором. Полтора часа разговора это единственное место, где сказано, чего они хотят на самом деле, а не что написано в общем описании. Я вытащил оттуда 55 отдельных утверждений: требования, ограничения скоупа, болевые точки, сигналы для скоринга, факты про их процесс.
Знание нужно разложить, а не прочитать. Я прогнал транскрипт и исследовательские документы через свой пайплайн, который превращает встречи и документы в структурированную базу: каждое утверждение получает тип, идентификатор и ссылку на источник. На выходе сто с лишним айтемов в трёх батчах, из них 27 сигналов для скоринга и 4 зафиксированных риска. Дальше по этой базе строился бэклог. Это не про инструмент, это про принцип: если не разложить знание на адресуемые куски, оно останется ощущением, а не основанием для решений.
Продуктовые инварианты вперёд кода. Из ответов спонсора родились правила, которые нельзя ломать даже ради упрощения. Например: три оси скоринга никогда не усредняются в одну цифру, потому что среднее прячет расхождение, а расхождение это и есть самый интересный сигнал. Или: если данных нет, вниз идёт уверенность системы, а не оценка фаундера. Эти правила висели перед глазами весь хакатон и снимали половину споров «как сделать проще».
Чужие решения как карта, а не как код. Девять открытых проектов на смежные темы я разобрал не чтобы копировать, а чтобы понять, что все делают одинаково. Оказалось: почти все смотрят только со стороны инвестора и оценивают то, что уже видно. Значит, дифференциация лежит ровно там, где никто не работает.
Свежесть сигналов важнее их списка. Отдельно проверял, какие сигналы в 2026 году всё ещё что-то значат. Звёзды на GitHub давно тщеславная метрика. Наличие прототипа обесценилось, потому что прототип теперь собирается за вечер. Зато остались вещи, которые подделать дорого: смерженные пул-реквесты в чужие репозитории, ревью чужого кода, регулярность работы вдолгую.
К моменту, когда началась разработка, у меня были не идеи, а зафиксированные требования с источниками.
Что в итоге построилось
Продукт для венчурного фонда, четыре стадии: поиск, скрининг, проверка, решение. Целевой сегмент: фаундеры и стартапы на самых ранних стадиях, у которых ещё нет трек-рекорда и которых существующие венчурные инструменты структурно не видят.
Два входа, одна воронка. Это принципиальный момент, и он часто теряется при пересказе.
Первый вход, входящий: фаундер подаёт заявку сам. Вход намеренно минимальный: название компании, почта, дек. Больше ничего не обязательно, потому что избыточная форма работает против вас: она отсеивает сильнее всего именно квалифицированных кандидатов. Дальше система задаёт до трёх опциональных вопросов, и они не произвольные. Считается арифметически, какие критерии скоринга принципиально недостижимы из публичных источников, и спрашивается ровно про них. В нашей модели это первые клиенты, конкретность целевого сегмента и инсайдерское знание конкурентов: вместе почти 30% оценки фаундера, которую снаружи не увидеть никак. Любой вопрос пропускается в один клик.
Второй вход, исходящий: радар сам находит тех, кто ещё никуда не подавался. Сканируются публичные следы: GitHub, Show HN, личные сайты. Карточка фаундера заводится без дека и попадает в ту же воронку.
Дальше обе стороны обрабатываются одинаково: outbound-находка проходит ровно тот же скоринг, что и входящая заявка. Смысл исходящего поиска не в том, чтобы инвестировать вслепую, а в том, чтобы спровоцировать реальную заявку от человека, который сам бы до фонда не дошёл.
Скоринг по трём независимым осям: фаундер, рынок, попадание идеи в рынок. У каждой оси свой тренд. В одну цифру они не схлопываются никогда.
Проверка каждого утверждения отдельно. Выручка, трекшн, бэкграунд команды, размер рынка: каждое утверждение трассируется к источнику и получает свой уровень доверия. Противоречия ловятся до того, как дойдут до инвестора. В демо-данных специально зашиты противоречия, и пайплайн их действительно находит.
Честность как функция. Нет данных про капитализацию: система пишет «не раскрыто», а не додумывает. Меморандум, который явно помечает свои пробелы, для инвестора полезнее вылизанного и уверенного.
Оценка фаундера, которая живёт с человеком. Она не привязана к конкретной компании, не обнуляется при новом стартапе и уточняется с каждой новой вехой.
Доступ и для людей, и для агентов. Веб-интерфейс плюс API и CLI, чтобы агенты фонда могли обращаться к системе напрямую.
На выходе: инвест-меморандум и рекомендация по чеку, с которыми инвестор может действовать в тот же день.
Цифры по факту сдачи: 12 фич, 75 коммитов, 22 workflow в n8n, около 900 автотестов. Стек: Supabase (Postgres), n8n, OpenAI, Tavily, всё в Docker, задеплоено на VPS. Живая цепочка отрабатывает от заявки фаундера до готового меморандума за 2.5 минуты полностью автоматически.
Как это делается одним человеком
Ключевое решение: я не пытался написать всё сам. Команду разработки заменили Claude и Codex.
Пайплайн при этом был совершенно стандартный, SDD: сначала спецификация, потом план, потом ревью плана, и только потом код. Ничего экзотического, просто выдержанное до конца.
Процесс на каждую фичу выглядел так:
- Спецификация. Сначала все источники на вход: внутренняя база требований, NotebookLM, Exa, собственная RAG-база и Telegram-корпус, разбор девяти чужих решений. Потом варианты, выбор, перепроверка выбранного по тем же источникам. Дизайн-док кладётся в папку фичи.
- План. Пишет один агент, ревьюит другой, правится циклом до явного APPROVED. Этот шаг легко хочется пропустить ради скорости, и именно он экономит больше всего времени.
- Параллельное исполнение. Независимые стадии разбираются одновременно: отдельные агенты на бэкенд, фронтенд, базу данных и деплой. Зависимые идут последовательно. Фронт всегда через отдельный бриф с замороженными контрактами API: тогда интерфейс и бэкенд строятся одновременно, а не по очереди.
- QA-гейт через Playwright. Отдельный агент сам открывал браузер, сам прогонял сценарии и выносил вердикт. Без пройденного гейта фича не считалась сделанной. Это то, что отличает «вроде работает» от «проверено».
- Трекер исполнения. Таблица «задача, агент, статус, результат» обновляется оркестратором постоянно. Это то, что позволяет восстановиться после любого сбоя с любой точки.
Фронт собирал в Lovable и Claude Design: генерация экранов, потом разворачивание исходников у себя и доводка.
Правило было жёсткое: работа руками в главном контексте запрещена. Главная модель только оркестрирует: ставит задачи, сводит результаты, держит инварианты. Часть фич шла в параллельных терминалах одновременно, и именно это дало скорость: за ночь закрылась целая волна независимых фич.
Чем пришлось заплатить
Честная часть.
Потеря работы из-за параллельности. Дважды за хакатон случилось одно и то же: несколько терминалов правили общие файлы схемы базы данных, но никто из них эти правки не коммитил. Одна лишняя команда в соседнем окне стёрла часы работы сразу трёх фич. Спасло только то, что объекты были уже применены в живой базе и схему удалось восстановить оттуда. Если бы контейнер перед этим перезапустили с чистого листа, работа просто исчезла бы.
Вывод, который стоил дороже всего: общие файлы коммитятся в тот же час, когда правятся. Не «в конце фичи», не «перед сдачей». Как только у вас больше одного агента, пишущего в общий файл, некоммиченная работа это работа, которой нет.
Скоуп больше, чем время. Из 12 фич две не дошли до состояния «закрыто». По каждой закрытой фиче остались известные открытые пункты, которые я честно записал вместо того, чтобы делать вид, что их нет.
Сдача это отдельный проект. Требовалось три видео: демо продукта, техническое и рассказ о команде. Даже для соло это три записи. Плюс краткое описание, публичный репозиторий, архив с кодом. Время под это нужно закладывать заранее, а не в последний час.
Общий сбой на сдаче. Часть файлов не долетела из-за технической проблемы на стороне платформы, и всем участникам пришлось перезаливать видео отдельной формой. Сроки объявления финалистов сдвинули на неделю.
Что я забираю из этого опыта
Соло больше не означает «успею меньше». Оно означает «всё упирается в то, насколько точно ты ставишь задачу». Скорость перестала быть функцией количества рук.
Роль сместилась с исполнителя на оркестратора. Декомпозиция, инварианты, приёмка результата. Это ровно то, чем продакт занимается каждый день, только цикл сжался с недель до часов. Мой шестнадцатилетний опыт в продукте здесь пригодился больше, чем любой навык кодинга.
Незнакомая ниша перестала быть барьером. Она стала вопросом качества работы с источниками за первые несколько часов. Тот, кто разложил бриф на адресуемые требования, обгоняет того, кто его просто прочитал.
Дисциплина процесса важнее скорости печати. Гейты, трекеры, ревью планов выглядят как оверхед на 24-часовом спринте. По факту именно они позволили не потерять управление, когда параллельно шло пять веток работы.
Что дальше
Результатов пока нет: финалистов объявляют до 30 июля, живые питчи и награждение 1 августа. Как узнаю, расскажу, независимо от исхода.
Код проекта открыт: https://github.com/Serg1kk/the-vc-brain