Задача
«Подготовить стартап к инвестициям» — фраза без содержания. На практике основатель не знает, что именно у него не готово, а инвестор не может сравнивать проекты: каждый рассказывает о себе по-своему и подтверждает слова презентацией. Между ними — разрозненные чаты, диски с файлами, таблицы задач и переписка, из которых невозможно восстановить, на каком основании проект считается зрелым.
Ещё сложнее с доступом. Публичный интерес к проекту, членство в команде и допуск к финансовым документам — три разные вещи, и в одной системе они не должны наследоваться друг из друга автоматически. Плюс новостной поток: единая лента для всех бесполезна, потому что релевантность материала зависит от отрасли, стадии и содержания конкретного проекта.
Решение
Чек-лист зрелости как ядро продукта. У каждой стадии свои требования: описание проблемы и целевой аудитории, результаты интервью и подтверждение спроса, бизнес-план и business model canvas, конкурентный анализ, прототип и сценарий пилота, экономика продукта и финансовая модель, состав команды и распределение ответственности, юридические документы, презентация для инвесторов. К пунктам прилагались шаблоны и примеры, поэтому основателю не приходилось угадывать структуру каждого документа. Загруженный материал привязывался к конкретному требованию, хранил версии и получал статус проверки; незакрытые обязательные пункты были видны сразу.
Переход стадии — событие, а не поле в базе. Система проверяла обязательные результаты, фиксировала решение проверяющего и сохраняла историю. Получался evidence trail: по любому проекту можно было восстановить, на основании каких именно материалов он получил статус готовности. Это и делало проекты сопоставимыми для инвестора — зрелость подтверждалась выполненными требованиями, а не убедительностью питча.
Три независимых порога доступа. Пространство проекта закрыто, пока идёт ранняя работа. Публичный профиль собирается из утверждённых данных — проблема, решение, рынок, стадия, команда, открытые роли, инвестиционный статус — и открывается только после достижения критериев площадки, что отсекает из каталога пустые идеи без материалов. Инвестиционные документы лежат за третьим порогом: инвестор отправляет запрос, площадка проверяет стороны и права, и только тогда открывается data room, где просмотр, скачивание и участие в обсуждении задаются на уровне отдельного документа.
Заявка в команду с собственным жизненным циклом. Отправлена — рассматривается — требуется уточнение — принята или отклонена. После принятия система создавала членство в проекте и выдавала права выбранной роли. Так публичный интерес к стартапу отделялся от реального доступа к его внутренним материалам, а основатель мог ограничить видимые разделы или отозвать доступ.
Taskboard, сцепленный с методологией. Задачи с исполнителями, сроками и приоритетами, roadmap и зависимости между этапами, общая библиотека документов с историей версий, обсуждения, календарь и история решений живут внутри проекта, а не рядом с ним: выполненная задача может закрывать требование этапа, обновлять roadmap или создавать материал для последующей проверки.
Гибридные рекомендации новостей. Материал проходил загрузку, очистку и нормализацию; из него выделялись тема, отрасль, компании, технологии, география и стадия бизнеса. Контентный сигнал строился на эмбеддингах — статья о прослеживаемости сырья могла оказаться релевантна стартапу из circular economy, хотя формулировки в тексте и в профиле проекта не совпадали. Коллаборативный сигнал брался из поведения пользователей с похожими интересами и проектами: открытия, дочитывания, сохранения, реакции, подписки и пропуски. Кандидаты объединялись и ранжировались по близости к проектам и интересам, поведению похожих пользователей, стадии стартапа, свежести, языку и доступности перевода, повторам и разнообразию источников. Холодный старт закрывался анкетой, выбранными интересами и данными созданного проекта. RapidMiner использовался для подготовки данных и сборки пайплайнов: в модели уходили обезличенные события поведения и метаданные контента, обратно приходил ранжированный набор кандидатов.
Администрирование с разделением зон. Модерация профилей, проектов и публикаций, подтверждение личности основателей и инвесторов, настройка стадий, чек-листов и шаблонов, очереди проверки зрелости, спорные доступы, контроль инвестиционных запросов и договорного процесса, управление источниками новостей, мониторинг свежести выдачи, журнал по чувствительным операциям. Права делились по ответственности: модератор контента не получал доступ к инвестиционным документам, а оператор сделки не менял настройки рекомендательной модели.
Результат
Вместо набора чатов, дисков и таблиц все стороны работали в одном пространстве с общим языком зрелости. Основатель видел, что именно мешает проекту перейти на следующую стадию, и получал шаблон вместо пустого листа. Кандидат понимал, в какую команду и на какую роль подаётся, а после принятия заявки сразу получал права и рабочий контекст. Инвестор работал с проектами, прошедшими сопоставимую проверку, и с материалами, доступ к которым выдан явно. Площадка вела сделку как процесс — от запроса и проверки сторон до согласования договорных документов и фиксации статуса — и сохраняла историю каждого шага. Новости при этом перестали быть отдельным медиа-разделом: лента опиралась на содержание проекта и его стадию и работала как инструмент развития.
