Как понять, что продукт технически готов к первому крупному клиенту

Чек-лист и фреймворк для CTO, VP Engineering и Tech Lead

Введение: почему «работает у нас» не значит «готово у них»

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

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

По данным отчёта Cortex о готовности к продакшену за 2024 год, 98% технических руководителей сталкивались с серьёзными последствиями от запуска сервисов без должной подготовки. [1] 68% сделок по технологическим продуктам, по оценке Deloitte, сталкиваются с задержками из-за непроверенного технического стека. [2]

Задача этой статьи — дать конкретный фреймворк: что проверить, как измерить, что показать клиенту, и где обычно прячутся скрытые риски.

Часть 1. Что именно проверяет крупный клиент

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

Vendor security assessment

Большинство enterprise-компаний перед заключением контракта проводят оценку безопасности поставщика. В России и СНГ к стандартным процедурам добавляется соответствие 152-ФЗ (защита персональных данных) и 187-ФЗ (критическая информационная инфраструктура) — для компаний из регулируемых секторов. [3]

Типовой запрос включает:

1. Документацию по архитектуре и размещению данных.
2. Политику управления уязвимостями и историю патчей.
3. Отчёт о проведённых пентестах или результаты сканирования (SAST/DAST/SCA).
4. Политику резервного копирования и восстановления.
5. Политику управления доступом и аутентификацией.
6. Сведения о субподрядчиках и цепочке поставок ПО.

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

Technical due diligence

Технический due diligence — более глубокий процесс, который охватывает кодовую базу, архитектуру, инфраструктуру, процессы разработки и зрелость команды. Ключевые вопросы: [4]

1. Может ли система масштабироваться под прогнозируемую нагрузку?
2. Как вы управляете инцидентами и сколько времени занимает восстановление?
3. Каков технический долг и сколько ресурсов он поглощает?
4. Насколько предсказуем процесс разработки и релизов?
5. Кто владеет исходным кодом, пайплайнами и инфраструктурными аккаунтами?

Часть 2. Шесть областей технической готовности

2.1 Инфраструктура и надёжность

Первое, что запрашивает enterprise-клиент — условия SLA. Стандарт для серьёзного контракта — 99,9% uptime, что означает не более ~8,7 часов простоя в год. Для критичных систем ожидается 99,95% или выше. [5]

Но uptime-метрика — это ещё не вся история. Клиента интересуют конкретные параметры восстановления:

• RTO (Recovery Time Objective) — сколько времени займёт восстановление после сбоя.
• RPO (Recovery Point Objective) — сколько данных вы можете потерять в худшем случае.

Для продукта, работающего с бизнес-данными клиента, типичные ожидания: RTO до 4 часов, RPO — не более нескольких часов. Финансовые и медицинские системы требуют значительно меньших значений. [6]

Что нужно подготовить до переговоров:

1. Задокументированные SLA с конкретными цифрами, а не «высокая доступность».
2. Историю uptime за последние 6–12 месяцев из независимых источников мониторинга.
3. Документированный план disaster recovery с тестами.
4. Многозонное или многорегиональное развёртывание либо чёткую архитектурную дорожную карту к нему.
5. Проверенные процедуры rollback при деплое.

Google SRE-книга, определившая стандарты Production Readiness Review (PRR) в индустрии, формулирует цель проверки так: убедиться, что сервис соответствует принятым стандартам продакшен-среды и что его владельцы готовы реагировать на инциденты. [7] Это не one-time check, а непрерывный процесс — по данным Cortex, 32% организаций не имеют такого процесса и обнаруживают деградацию только в момент инцидента. [1]

2.2 Безопасность и управление доступом

Enterprise-клиент не просто хочет, чтобы его данные были «в безопасности» — он хочет понять, как именно организована эта безопасность и можно ли это проверить.

Минимальный набор, без которого сложно закрыть сделку с зрелой компанией:

Аутентификация и управление доступом:

1. Поддержка SSO через SAML или OIDC для интеграции с корпоративными провайдерами идентификации (Okta, Azure AD, Keycloak и аналоги). [8]
2. RBAC (Role-Based Access Control) с настройкой на уровне организации: кто может читать, кто — менять, кто — администрировать.
3. SCIM-provisioning для автоматизации управления жизненным циклом пользователей.
4. Многофакторная аутентификация как обязательный элемент, а не опциональная настройка.

Шифрование и изоляция данных:

1. Шифрование данных в покое (at rest) и при передаче (in transit).
2. Чёткая политика multi-tenancy: как данные одного клиента изолированы от данных другого.
3. Политика хранения и удаления данных, готовность к data residency requirements.

Управление уязвимостями:

1. Задокументированный процесс управления уязвимостями: как вы узнаёте о новых CVE в зависимостях, в какие сроки патчите критические.
2. История проведённых пентестов или сканирований с доказательствами.
3. Bug bounty или ответственное разглашение (responsible disclosure policy).

В России и СНГ к этому добавляется соответствие 152-ФЗ и, для ряда отраслей, 187-ФЗ: крупные корпорации проводят собственный аудит ПО перед размещением в своём ИТ-контуре — процедуру, которую они называют «проверкой на уязвимости» или «ИБ-аудитом вендора». [3] Это может включать SAST, DAST, SCA и ручной пентест — и занимает от двух недель до нескольких месяцев в зависимости от регламентов клиента.

Международный уровень: SOC 2 Type II всё активнее становится стандартом для enterprise-продаж за рубежом. По данным отраслевого исследования, более 60% компаний с большей вероятностью заключат контракт со стартапом, имеющим SOC 2, и более трети организаций уже теряли сделки из-за отсутствия сертификации. [9] Процесс занимает от 3 до 6 месяцев — если начинать его за день до переговоров, сделка будет потеряна.

2.3 Состояние кода и зависимостей

Это область, которую команды недооценивают сильнее всего — и которая чаще всего вскрывается при техническом due diligence.

Работающий PR не обязательно безопасен. Зависимость с известной уязвимостью, принятая несколько месяцев назад, может стать причиной отказа от сделки — или, что хуже, стать вектором атаки уже после подписания контракта.

Что нужно проверить:

1. Все прямые и транзитивные зависимости известны и отслеживаются (SBOM — Software Bill of Materials).
2. Нет зависимостей с активными критическими CVE без документированного обоснования.
3. Lock-файлы используются и актуальны, версии зафиксированы.
4. Нет секретов, захардкоженных в репозиторий (ключи API, пароли, токены).
5. Конфигурационные файлы, миграции баз данных и CI/CD-пайплайны проходят code review — не только бизнес-логика.

В контексте AI-ускоренной разработки этот риск становится острее: когда код пишется быстро, review сокращается, а новые зависимости добавляются без полного анализа. Рабочий pull request — не гарантия отсутствия проблем в supply chain.

2.4 Наблюдаемость (observability)

Enterprise-клиент задаст вопрос: «Как вы узнаёте о проблемах до того, как о них узнаём мы?» Если ответа нет — это красный флаг.

Зрелая наблюдаемость включает три столпа:

1. Метрики: latency, error rate, saturation, traffic (USE/RED методологии). Ключевые метрики должны быть доступны в реальном времени.
2. Логи: структурированные, с retention policy, доступные для запросов в разумные сроки.
3. Трейсы: распределённая трассировка запросов для диагностики проблем в микросервисной архитектуре.

Это не просто технический стандарт. Enterprise-клиент ожидает status page, runbook для типовых инцидентов и чёткий процесс нотификации: кто, когда и как сообщает о сбоях.

DORA-метрики (исследование Google/DevOps Research and Assessment) дают измеримый ориентир. Elite performers: развёртывание несколько раз в день, MTTR (время восстановления после инцидента) менее часа, change failure rate ниже 5%. [10] Если ваши показатели далеки от этих значений — честно зафиксируйте текущее состояние и покажите динамику улучшений.

По данным DORA Report 2024, высокая частота деплоев коррелирует с более высокой стабильностью — это контринтуитивно, но подтверждается годами исследований. [11] Команды, деплоящие чаще, быстрее обнаруживают и исправляют проблемы, а не накапливают батчи рискованных изменений.

2.5 API и интеграция

Крупные клиенты не используют ваш продукт изолированно. Им нужно встроить его в существующую экосистему: CRM, ERP, LDAP, SIEM, тикетные системы. API-контракт — это не техническая деталь, это стратегическое обязательство.

Что требует проверки:

1. API документировано (OpenAPI/Swagger или эквивалент) и актуально.
2. Есть явное версионирование с политикой deprecation и временем поддержки старых версий.
3. Аутентификация через API-ключи или OAuth с возможностью scope-ограничения.
4. Rate limiting задокументирован и предсказуем.
5. Есть sandbox/staging среда для тестирования интеграций без риска для продакшена.
6. Webhook'и или события для событийно-ориентированных интеграций.

Enterprise-клиенты не могут позволить себе внезапные breaking changes. Отсутствие чёткой политики версионирования — один из первых сигналов незрелости платформы. [8]

На российском рынке отдельное внимание уделяется документации по интеграции при проведении тендеров: отсутствие чёткой документации по API, форматам обмена и поддерживаемым протоколам — одна из частых причин технического отказа. [12]

2.6 Операционные процессы

Технологии важны, но enterprise-клиент также оценивает, как устроены процессы вокруг них. Самый надёжный продукт, обслуживаемый командой без чёткого incident management и on-call, — это риск.

Минимальный операционный стандарт:

1. Задокументированный процесс incident response: кто дежурит, как эскалируется инцидент, в какие сроки клиент получает уведомление.
2. Runbooks для типовых сценариев отказов.
3. История постмортемов: не просто «мы исправили», а что произошло, почему, и что изменилось в процессах.
4. Change management: как проходит деплой изменений, есть ли freeze-окна, как согласуются потенциально рискованные изменения.
5. Чёткая политика поддержки с SLA на время ответа (не только на uptime).

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

Часть 3. Decision framework: готовы ли вы сейчас?

Пройдите по каждому вопросу ниже. Если ответ «нет» или «не знаю» — это работа, которую нужно сделать до переговоров, а не в их процессе.

Инфраструктура и надёжность:

1. Есть ли задокументированный SLA с конкретными цифрами (uptime %, RTO, RPO)?
2. Есть ли история uptime за последние 6 месяцев из системы мониторинга?
3. Тестировался ли план disaster recovery в последние 6 месяцев?
4. Есть ли автоматизированный rollback при ошибочном деплое?

Безопасность:

1. Поддерживается ли SSO (SAML/OIDC)?
2. Реализован ли RBAC на уровне организации?
3. Шифруются ли данные at rest и in transit?
4. Есть ли задокументированный процесс управления уязвимостями в зависимостях?
5. Проводился ли пентест или независимый ИБ-аудит в последние 12 месяцев?
6. Нет ли секретов в репозитории?

Код и зависимости:

1. Существует ли SBOM (актуальный список всех зависимостей)?
2. Нет ли зависимостей с известными критическими CVE без задокументированного решения?
3. Проходят ли конфигурационные файлы, миграции и CI/CD code review?

Наблюдаемость:

1. Есть ли метрики latency, error rate и saturation в реальном времени?
2. Есть ли публичная или доступная клиентам status page?
3. Задокументирован ли процесс нотификации о сбоях?

API и интеграция:

1. Задокументировано ли API (OpenAPI или аналог)?
2. Есть ли явное версионирование с политикой deprecation?
3. Есть ли sandbox-среда для тестирования интеграций?

Операционные процессы:

1. Есть ли задокументированный incident response с checklists и runbooks?
2. Есть ли история публичных или предоставляемых клиентам постмортемов?
3. Определены ли SLA на поддержку (время первого ответа, время решения)?

Если зелёных ответов меньше половины по какому-либо блоку — это приоритет ближайшего квартала, а не когда-нибудь.

Часть 4. Типичные ошибки и риски

«Мы исправим это потом»

Самая дорогая ошибка — откладывать готовность до момента, когда крупный клиент уже на пороге. Production readiness checklist, появившийся «за две недели до закрытия сделки», не убеждает никого.

Согласно State of Software Production Readiness 2024, лишь 6% инженеров обновляют метаданные сервисов (документацию, мониторинг) ежедневно, а более 40% — делают это нерегулярно. [13] Когда это вскрывается в процессе due diligence — клиент видит не техническую деталь, а сигнал об операционной культуре.

«Работает в dev — значит, готово к prod»

«Product readiness» и «production readiness» — разные вещи. Первое отвечает на вопрос «стоит ли это выпускать?», второе — «можем ли мы безопасно это поддерживать?» [14] Функционально рабочий продукт без observability, runbooks и истории инцидентов — это не enterprise-ready продукт.

Зависимости как слепая зона

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

Инструменты типа HighVibe (highvibe.dev) работают именно в этой точке: анализируют конкретное изменение в коде, конфигурации или зависимостях до merge и релиза — помогая заметить риск до того, как он доедет до продакшена клиента.

Несогласованные стандарты между командами

По данным Cortex, 66% технических руководителей называют несогласованность стандартов между командами главным барьером на пути к масштабируемой готовности. [1] Один сервис уходит к клиенту с хорошим мониторингом, другой — с пробелами. В глазах enterprise это не «один сервис сырой», а «процессы не устоялись».

Откат к ручным процессам под давлением

При высокой нагрузке (клиент на пороге, дедлайн давит) команды возвращаются к ручным деплоям, пропускают ревью и деактивируют проверки «временно». Именно в такие моменты происходят инциденты, которые разрушают первое впечатление.

Часть 5. Что показать клиенту

Техническая готовность — это не только то, что у вас есть внутри. Это то, что вы можете предъявить.

Типовой пакет документов для enterprise-переговоров:

1. Security overview: архитектура безопасности, используемые инструменты, процессы управления уязвимостями.
2. Trust & Compliance page (публично или по запросу): статус сертификаций, история ИБ-аудитов, политика ответственного разглашения.
3. Status page: история инцидентов, время восстановления, текущее состояние сервиса.
4. SLA-документ: конкретные числа uptime, RTO, RPO, поддержка.
5. API-документация с changelog и политикой versioning.
6. SBOM или заявление о политике управления зависимостями.
7. Data processing agreement (DPA) или аналог — особенно актуально при работе с персональными данными.

Компании, систематически публикующие Trust Center и поддерживающие актуальный статус, закрывают первый этап vendor security assessment до начала переговоров. Это сокращает цикл сделки.

Часть 6. Тренды: что меняется в ближайшие 1–2 года

Supply chain security становится обязательным требованием. После инцидентов с атаками на цепочку поставок ПО (Log4Shell, xz-utils, polyfill.io) корпоративные ИБ-службы планомерно ужесточают требования к SBOM и к тому, как вендор управляет транзитивными зависимостями. [15]

Compliance-автоматизация ускоряется. Традиционно SOC 2 Type II занимал 3–6 месяцев. Современные инструменты автоматизации (Vanta, Drata, Comp AI и аналоги) позволяют сократить этот путь — но автоматизация процесса не отменяет необходимость выстроенных контролей. [9]

AI-ускоренная разработка создаёт новый класс рисков. Code review не успевает за скоростью генерации — и ИБ-проблемы начинают приезжать не через уязвимости в написанном от руки коде, а через AI-предложенные зависимости, конфиги с широкими правами или отладочные настройки, оставленные в релизе. [16]

Digital Due Diligence стандартизируется. По данным исследования 2025 года, более 70% PE-фондов и стратегических инвесторов включают оценку цифровой зрелости в due diligence. Это означает, что enterprise-клиенты всё чаще применяют те же фреймворки — DDD на основе ISO 27001, SOC 2, NIST CSF. [2]

Заключение: что делать дальше

Техническая готовность к первому крупному клиенту — не финальная точка, а стартовая. Её нужно выстроить однажды и поддерживать непрерывно.

Практический план на ближайший квартал:

1. Пройдите по decision framework из части 3. Зафиксируйте реальное состояние по каждому блоку — честно, а не как хотелось бы видеть.
2. Определите три критических пробела, которые клиент точно заметит в процессе due diligence. Закройте их первыми.
3. Запустите минимальный набор observability, если его нет: метрики latency + error rate + status page.
4. Проведите внутренний ИБ-аудит или привлеките внешнего консультанта — до, а не во время переговоров.
5. Начните формировать trust документацию: SLA, security overview, история инцидентов.
6. Настройте непрерывный контроль состояния зависимостей — особенно если разработка ускоряется с AI-инструментами.

Enterprise-сделки проигрываются не потому, что продукт плох. Они проигрываются потому, что на вопрос «как вы узнаёте о проблеме до нас?» нет чёткого ответа.

Источники

[1] Cortex — "We need to talk about production readiness" — https://www.cortex.io/post/we-need-to-talk-about-production-readiness

[2] Hackitect7 (Medium) — "Digital Due Diligence 2025" — https://hackitect7.medium.com/digital-due-diligence-2025-how-to-assess-it-infrastructure-maturity-before-investments-and-m-a-44df9e686462

[3] ЦУС Академия — "Как процедуры ИБ обеспечивают защиту корпоративных данных: алгоритм проверок и примеры требований для ПО вендора" — https://academy.tsus.ru/kak-proczedury-ib-obespechivayut-zashhitu-korporativnyh-dannyh-v-stroitelnyh-proektah-algoritm-proverok-i-primery-trebovanij-dlya-po-vendora/

[4] GainHQ — "Technical Due Diligence Checklists For Tech Teams" — https://gainhq.com/blog/technical-due-diligence/

[5] Opsio — "RPO and RTO Explained: How to Set Recovery Objectives" — https://opsiocloud.com/blogs/rpo-rto-explained-how-to-set-recovery-objectives/

[6] Hexnode — "Disaster Recovery Specs: RTO/RPO for the Enterprise" — https://www.hexnode.com/blogs/disaster-recovery-specs-rto-rpo-for-the-enterprise/

[7] Google SRE Book — "Evolving SRE Engagement Model / Production Readiness Review" — https://sre.google/sre-book/evolving-sre-engagement-model/

[8] Logto — "How to make your product Enterprise-Ready: The complete checklist" — https://blog.logto.io/enterprise-ready

[9] Comp AI — "SOC 2 Checklist for SaaS Startups: Complete Guide 2025" — https://trycomp.ai/soc-2-checklist-for-saas-startups

[10] GitLab — "DORA Metrics" — https://about.gitlab.com/topics/devops/dora-metrics/

[11] RedMonk — "DORA Report 2024 — A Look at Throughput and Stability" — https://redmonk.com/rstephens/2024/11/26/dora2024/

[12] B2B Irkutsk Energo — "Тендеры на ПО 2025: как успешно пройти отбор" — https://b2b-irkutskenergo.ru/tendery/kak-vyigrat-tender-na-soft-v-2025-prakticheskoe-rukovodstvo-dlya-postavschikov/

[13] Port.io — "Production readiness checklist: ensuring smooth deployments" — https://www.port.io/blog/production-readiness-checklist-ensuring-smooth-deployments

[14] GetDX — "Production readiness checklist for dependable releases" — https://getdx.com/blog/production-readiness-checklist/

[15] Iterators — "Vendor Security Assessment: The Enterprise Checklist SaaS Startups Miss" — https://www.iteratorshq.com/blog/vendor-security-assessment-the-enterprise-checklist-saas-startups-miss/

[16] Peiko — "Launching a SaaS in 2026? Don't Skip This Security Checklist" — https://peiko.space/blog/article/saas-security-checklist-before-launch