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