Разработка сайта под ключ для B2B SaaS, маркетплейсов и fintech 2026

Что описывает эта статья, а что нет. Разработка сайта под ключ и веб-продукта по вертикалям — B2B SaaS, marketplace, fintech, healthtech — отраслевая специфика архитектуры, compliance и интеграций. Это не общий процесс разработки под ключ (см. разработку под ключ — про добавление функционала к зрелому продукту) и не про одиночные узкие фичи (см. разработку фичи).

Универсальные обещания «разработка сайта под ключ» не покрывают специфики вертикалей. B2B SaaS требует мультитенант-архитектуры и SSO-интеграций. Маркетплейсы — нагрузочной оптимизации и десятков внешних интеграций. Fintech — compliance с регуляторикой ЦБ и обязательным security audit. CTO, выбирающий вендора для разработки сайта под ключ в конкретной вертикали, должен понимать специфику и выбирать команду с реальным опытом именно в этой нише.

Эта статья — для CTO B2B SaaS, маркетплейсов и fintech-компаний, которые планируют разработку сайта или веб-продукта под ключ. Внутри: типовые задачи в каждой вертикали, специфика архитектуры и compliance, реалистичные сроки и бюджеты, как выбирать вендора.

B2B SaaS: мультитенант, биллинг, SSO

B2B SaaS — это продукт для бизнеса с подписочной моделью, корпоративными покупателями, сложными интеграциями. На 2026 год большая часть задач под ключ в B2B SaaS относится к расширению функциональности зрелого продукта.

Типовые задачи под ключ

1. Мультитенант-функциональность. Изоляция данных между клиентами (тенантами), role-based access control, per-tenant конфигурация. Срок — 8-12 недель для перевода существующего продукта в мультитенант, 4-8 недель для расширения уже мультитенантного продукта.

2. Биллинг и подписки. Интеграция со ЮKassa, Tinkoff Acquiring, Сбербанк Эквайринг для российского рынка; recurring billing, инвойсы, акты, налоговая отчётность (54-ФЗ, онлайн-кассы). Срок — 10-14 недель для полного биллинга, 6-8 недель для интеграции с существующим биллингом.

3. SSO и enterprise-аутентификация. SAML 2.0, OIDC, интеграция с Active Directory клиента (Microsoft AD для legacy-клиентов, ALD Pro для государственных). Корпоративные заказчики B2B SaaS почти всегда требуют SSO. Срок — 6-10 недель.

4. Открытое API для интеграций. REST API с rate limiting, webhooks, OAuth 2.0, SDK на популярных языках (Python, Node.js, PHP, Go). Документация Swagger/OpenAPI. Срок — 8-12 недель для полного API на новый функционал.

5. White-label и кастомизация. Возможность брендинга интерфейса под клиента (логотип, цвета, домен). Срок — 4-8 недель для базового white-label, 8-14 недель для глубокой кастомизации.

6. Аналитика и отчётность. Внутренний BI для пользователей SaaS, дашборды, экспорт. Срок — 8-12 недель.

7. Внутренние интеграции. С CRM (AmoCRM, Bitrix24, bpm’online), маркетинговыми инструментами, инструментами поддержки. Срок — 4-8 недель на одну интеграцию.

Архитектурная специфика

Главная особенность B2B SaaS — мультитенант на разных уровнях изоляции. Выбор уровня зависит от требований клиентов и регуляторики.

Уровень	Архитектура	Изоляция	Стоимость на тенант
Shared everything	Один экземпляр, одна БД, tenant_id как поле	Слабая	Минимальная
Shared app, separate DB	Один экземпляр приложения, отдельная БД на тенант	Высокая	Средняя
Schema per tenant	Один экземпляр, общая БД с отдельной схемой на тенант	Средне-высокая	Низкая
Full separation	Отдельный экземпляр на тенант	Максимальная	Высокая

Для большинства B2B SaaS на 2026 год — уровень 1-3. Уровень 4 — для enterprise-клиентов с регуляторными требованиями (банки, госсектор).

Сроки и бюджеты для B2B SaaS

Задача	Срок	Бюджет
Базовый мультитенант (новый продукт)	8-12 нед	2.5-4.5 млн ₽
Биллинг и подписки	10-14 нед	3-5 млн ₽
SSO (SAML + OIDC)	6-10 нед	1.5-3 млн ₽
Открытое API + SDK	8-12 нед	2.5-4 млн ₽
White-label	4-8 нед	1-2.5 млн ₽
Аналитика и BI	8-12 нед	2.5-4 млн ₽

Маркетплейсы: нагрузка, интеграции, расчёты

Маркетплейс — продукт со множеством продавцов, покупателей, операционных сервисов. Архитектурная сложность выше B2B SaaS из-за высокой нагрузки, многочисленных внешних интеграций и сложной бизнес-логики расчётов.

Типовые задачи под ключ

1. Интеграции с операторами маркетплейсов. Ozon, Wildberries, Yandex.Market, СберМегаМаркет, Lamoda. API для заказов, остатков, отзывов, цен. Каждый оператор имеет свою специфику API, rate limiting, форматы. Срок — 6-10 недель на одну интеграцию.

2. Системы управления товарными карточками (PIM). Массовая публикация, синхронизация, валидация по правилам каждой площадки, multi-source данных, версионирование. Срок — 10-16 недель.

3. Интеграции со складом и WMS. Резервирование товара, отгрузки, возвраты, инвентаризация. Срок — 8-14 недель.

4. Системы динамического ценообразования. Мониторинг конкурентов, автоматическая корректировка цен по правилам, репрайсеры для маркетплейсов. Срок — 10-14 недель.

5. Рекомендательные системы. ML-модели для cross-sell, up-sell, similar items, personalization. Срок — 12-16 недель.

6. Высоконагруженные части. Каталог с поиском (Elasticsearch, Manticore), корзина, оформление заказа. Нагрузка 100-1000 RPS на пике. Срок — 10-16 недель.

7. Системы возвратов и претензий. Workflow обработки возвратов, интеграция с операторами по возвратной логистике, финансовая часть. Срок — 8-12 недель.

Архитектурная специфика

Высокая нагрузка с пиками. Black Friday, Новый год, акции дают нагрузку в 5-20 раз выше обычной. Архитектура должна выдерживать peak load: горизонтальное масштабирование, кэширование (Redis), CDN для статики, очереди (Kafka/RabbitMQ) для асинхронной обработки. Нагрузочное тестирование — обязательная часть проекта под ключ для маркетплейса.

Сложная бизнес-логика расчётов. Комиссии маркетплейса, налоги, скидки, программы лояльности, валюта, доставка. Ошибки в расчётах прямо влияют на прибыльность. Стандарт — обширное unit-тестирование расчётной логики, отдельный QA-этап для проверки финансовых сценариев.

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

Сроки и бюджеты для маркетплейсов

Задача	Срок	Бюджет
Интеграция с одним оператором (Ozon/WB/YM)	6-10 нед	1.5-3 млн ₽
PIM (управление карточками)	10-16 нед	3.5-6 млн ₽
Интеграция со складом и WMS	8-14 нед	2.5-5 млн ₽
Динамическое ценообразование	10-14 нед	3-5 млн ₽
Рекомендательная система	12-16 нед	4-7 млн ₽
Высоконагруженный каталог	10-16 нед	4-7 млн ₽

Fintech: compliance, безопасность, регуляторика

Fintech — самая регулируемая вертикаль с самыми жёсткими требованиями к безопасности и compliance. Разработка под ключ для fintech требует специальной экспертизы и других контрактных условий.

Типовые задачи под ключ

1. Системы KYC (Know Your Customer). Интеграции с сервисами проверки клиентов (СМЭВ, бюро кредитных историй), скоринг, верификация документов. Срок — 12-16 недель.

2. Системы AML (Anti-Money Laundering). Мониторинг транзакций по правилам 115-ФЗ, выявление подозрительных операций, репортинг в Росфинмониторинг и ЦБ. Срок — 14-20 недель.

3. Платёжные шлюзы. Интеграции с НСПК (Национальная система платёжных карт), СБП (Система быстрых платежей), СПФС. Срок — 12-18 недель.

4. Интеграции с банками. Открытое банкинг (если есть), API банков для счетов, переводов, выписок. Срок — 8-14 недель на интеграцию с одним банком.

5. Системы расчётов и клиринга. Внутренняя книга записей, межбанковские расчёты. Срок — 16-24 недели.

6. Compliance-репортинг. Отчётность по 115-ФЗ, в ЦБ, в налоговую. Срок — 10-14 недель.

7. Криптография и защита информации. Интеграция с КриптоПро, ГОСТ-сертификаты, защищённые каналы (ViPNet, Континент). Срок — 6-12 недель.

Compliance-стандарт для fintech-разработки

Стандартный набор требований для российского fintech на 2026 год:

• 152-ФЗ-3 — обработка персональных данных. Классификация ИСПДн обычно К2-К3 с учётом банковских и финансовых данных. Модель угроз, организационные меры, технические меры из реестра ФСТЭК.
• 115-ФЗ — противодействие легализации преступных доходов. KYC и AML процедуры, репортинг.
• ФЗ-395-1 — банковская тайна (если работаете с банковскими данными).
• Положения ЦБ — 716-П (управление операционным риском), 757-П (отказоустойчивость), 5783-У (импортозамещение ИТ), 779-П (защита информации в банках), стандарт СТО БР ИББС.
• ФЗ-63 — электронная подпись, КриптоПро КЭП.
• ФСТЭК-сертифицированные СЗИ в зависимости от категории объекта КИИ (значимый или нет).

Структура fintech-проекта под ключ

В отличие от стандартного проекта под ключ, для fintech добавляются обязательные этапы.

1. Compliance-предпроектное обследование (1-2 недели). Помимо стандартного предпроектного обследования объёма работ — формирование требований compliance с участием compliance-команды клиента и юридического сопровождения.

2. Архитектурный design review с security-консультантом. До старта разработки. Оценка соответствия архитектуры требованиям 152-ФЗ, 115-ФЗ, ЦБ.

3. Параллельная подготовка compliance-документации. Модель угроз, политики обработки ПДн, регламенты, инструкции пользователей. Не «после разработки», а параллельно.

4. Двухуровневое security code review. Каждый PR проходит security review дополнительно к стандартному code review.

5. Security audit на pre-production. Внешний (от специализированной компании) или внутренний (если есть зрелый security-team у клиента).

6. Pen-test перед production. Чёрный или серый ящик — обязателен для fintech.

7. Расширенный SLA-период с security-сопровождением. Не только баги, но и security-патчи, мониторинг новых уязвимостей.

Сроки и бюджеты для fintech

Задача	Срок	Бюджет
KYC-модуль	12-16 нед	3.5-6 млн ₽
AML-модуль с репортингом	14-20 нед	4.5-8 млн ₽
Платёжный шлюз	12-18 нед	4-7 млн ₽
Интеграция с банком	8-14 нед	2.5-5 млн ₽
Compliance-репортинг	10-14 нед	2.5-4 млн ₽

Стоимость fintech-проектов под ключ на 30-50% выше стандартных аналогичной сложности из-за compliance, security audit и расширенного SLA. Это окупается снижением риска регуляторных проблем и инцидентов безопасности.

Как выбирать вендора для вертикальной разработки

Универсальный вендор может закрыть стандартный проект под ключ. Для вертикальных проектов нужна команда с реальным опытом именно в этой нише.

Что проверять при выборе вендора для B2B SaaS:

• Опыт с мультитенант-архитектурой (минимум 3-5 реализаций)
• Опыт со SSO-интеграциями (SAML, OIDC) в корпоративный AD/ALD Pro
• Опыт с биллингом и подписочной моделью
• Понимание B2B-продаж и enterprise-требований

Что проверять при выборе вендора для маркетплейса:

• Опыт интеграций с операторами (Ozon, WB, YM, СберМегаМаркет)
• Опыт нагрузочной оптимизации (peak load 500+ RPS)
• Опыт с PIM-системами
• Опыт с финансовыми расчётами (комиссии, скидки, лояльность)

Что проверять при выборе вендора для fintech:

• Опыт прохождения регуляторных проверок (ЦБ, Росфинмониторинг)
• Опыт с КриптоПро, КЭП, защищёнными каналами
• Опыт интеграций с НСПК, СБП, СПФС
• Compliance-консультант или security-эксперт в команде
• Опыт прохождения pen-test и security audit

Стандартная процедура отбора вендора для вертикального проекта — запрос 2-3 кейсов с подробностями, технический собеседование с tech lead вендора до подписания контракта, опционально — референсы от предыдущих клиентов.

Сопутствующие материалы — разработка под ключ, разработчики на проект 2026, фича под ключ: как принять результат, контракты разработки: фиксированная цена vs T&M, аутстафф vs под ключ.

Сравнительная таблица: вертикальные решения по отраслям

Отрасль	Типичный формат под ключ	Бюджет, млн ₽	Срок	Регуляторные требования
Fintech	Платёжный модуль, скоринг	3-8	10-16 нед	152-ФЗ, ЦБ РФ, KYC/AML
Healthtech	Интеграция с МИС, телемед	2-6	8-14 нед	152-ФЗ, ЕГИСЗ, лицензирование
Retail	Промо-механики, лояльность	1,5-4	6-12 нед	152-ФЗ, ОФД
Edtech	LMS-модули, прокторинг	1,5-3	6-10 нед	152-ФЗ, ФЗ «Об образовании»
Logistics	TMS, маршрутизация	2-5	8-14 нед	152-ФЗ, отраслевые
Manufacturing	MES, IIoT-интеграция	3-7	10-18 нед	Отраслевые ГОСТы
Real Estate	CRM, тур-генератор	1,5-3	6-10 нед	152-ФЗ, 214-ФЗ

Каждая отрасль накладывает свои регуляторные требования и предметные особенности. Универсальная команда под ключ без отраслевой экспертизы обычно недооценивает скрытые требования (например, тонкости интеграции с ОФД в retail или ЕГИСЗ в healthtech), что приводит к перерасходу сроков и/или провалу приёмки.

Что делает вертикальное решение под ключ эффективным

1. Готовый домен-знаниевой стек. Senior, который уже делал 3-5 платёжных модулей, не задаёт базовые вопросы про PCI DSS, 161-ФЗ, идемпотентность платежей.
2. Готовые ADR по типовым решениям. Не нужно с нуля решать «как делать reconciliation», есть шаблонный паттерн.
3. Знание подводных камней регулятора. Для fintech — это интеграции с ЦБ, для healthtech — с Росздравнадзором и ЕГИСЗ.
4. Партнёрские отношения с типовыми вендорами. Прямой контакт с поддержкой Тинькофф Кассы, ЮKassa, Сбербанк Эквайринг ускоряет интеграцию в 2-3 раза.
5. Шаблоны тестов и сценариев. Готовые наборы edge cases для типовых процессов отрасли.

Эти 5 факторов в сумме экономят 20-40% времени проекта и резко снижают риск пропуска критичных требований.

Антипример: универсальная команда в fintech-проекте

Корпоративный fintech заказал модуль скоринга под ключ у универсального подрядчика без специализации. Подрядчик не учёл требования 152-ФЗ к обработке специальной категории персональных данных, не предусмотрел логирование решений модели (требование ЦБ к ответственности за автоматизированные решения), не сделал реверсивную модель для разъяснения отказов. На приёмке выявилось: модуль работает технически, но не может быть запущен в production из-за регуляторных пробелов. Доработка — ещё 6 недель и 1,2 млн рублей. Урок: вертикальная экспертиза в fintech — это не «знаем Python и FastAPI», а «делали 5+ платёжных модулей с приёмкой ЦБ».

Чек-лист выбора вертикального подрядчика под ключ

• Подтверждённый опыт 3+ проектов в той же отрасли за последние 2 года
• Senior-составники команды с отраслевой экспертизой (не «вообще backend», а «backend для fintech 5+ лет»)
• Готовые шаблоны архитектуры под отрасль
• Знание ключевых нормативных требований (PCI DSS, 152-ФЗ, ЕГИСЗ, ОФД и т.д.)
• Партнёрские отношения с ключевыми отраслевыми вендорами
• Кейсы с измеримыми результатами (не «сделали хорошо», а «100K транзакций/день в production»)
• Подходящий формат для отрасли (фиксированная цена + 1-3 мес SLA для большинства)

Источники по вертикальным решениям

• ЦБ РФ: cbr.ru — для fintech, требования к информационной безопасности.
• ЕГИСЗ: egisz.rosminzdrav.ru — для healthtech.
• ОФД: ofd.ru и аналоги — для retail.
• Хабр: хабы по отраслям — fintech, healthtech, retail.
• Conf42, Highload++ — конференции с отраслевыми треками.

Связанные материалы — фича под ключ, разработка под ключ, команда разработчиков на проект.

Кейс: модуль расчёта комиссий и rolling-reserves для маркетплейс-агрегатора

Один из проектов 2026 года, иллюстрирующий специфику вертикальной разработки для маркетплейс-агрегатора (далее — Заказчик Г). Контекст: B2B-агрегатор, объединяющий продавцов на пяти крупнейших российских маркетплейсах под единым личным кабинетом; обслуживает 850 магазинов, GMV прохождения ~3,1 млрд рублей в год, in-house команда 22 разработчика.

Задача. Разработать модуль расчёта вознаграждения, удержаний и rolling-reserve по каждому продавцу с учётом специфики комиссионных структур пяти маркетплейсов; интегрировать с платёжной системой выплат; обеспечить полную прозрачность для аудита и регуляторных проверок.

Контекст вертикали. Это не общая «разработка модуля» — здесь есть отраслевые требования: 1) ФНС-совместимая агрегированная отчётность с возможностью реверсивной развязки до отдельной транзакции. 2) Поддержка различных комиссионных моделей у каждого маркетплейса (фиксированная, процентная, гибридная с минимумом-максимумом, бонусные программы). 3) Rolling-reserve как защита от чарджбэков и возвратов — отдельная сущность с timeline-зависимой логикой. 4) Интеграции с реальным временем — API маркетплейсов отдают данные с задержкой 24-72 часа, нужна reconciliation-логика с разрешением расхождений. 5) Прозрачность для проверок банка-партнёра (маркетплейс-агрегатор работает с банковскими счетами продавцов).

Архитектурное соответствие. Заказчик Г — на Python (Django REST Framework) с микросервисной архитектурой на gRPC. Модуль реализован как отдельный микросервис с собственной БД (PostgreSQL с partitioning по продавцам), общей шиной событий (NATS) для интеграции с другими сервисами Заказчика Г. ADR на 12 страниц, согласован с in-house Solution Architect Заказчика Г до старта.

Объём работ. 1) Модель данных: расчётный период, транзакция, комиссия, удержание, rolling-reserve, выплата. 2) Импорт операций из API пяти маркетплейсов с обработкой задержек и расхождений. 3) Движок расчётов: comissions, withholdings, reserves, currency conversion. 4) Reconciliation-процедуры — сверка расчётов с данными маркетплейсов и банка. 5) Workflow одобрения выплат с двойной авторизацией (ответственный + руководитель). 6) Аудит-логи всех изменений сумм. 7) Отчётность: ежедневная для операторов Заказчика Г, ежемесячная агрегированная для ФНС-формата, по запросу для регуляторных проверок банка. 8) Дашборд для продавцов с прозрачным показом всех начислений и удержаний.

Контракт. Фиксированная цена 5,8 млн рублей, срок 16 недель (с двухнедельной discovery-фазой 0,5 млн рублей перед основным контрактом, общий бюджет 6,3 млн). 134 критерия приёмки. Команда — Solution Architect, три senior backend (один с опытом fintech-расчётов 5+ лет), один senior DevOps, QA на парт-тайм. Двухуровневое code review с in-house Solution Architect Заказчика Г и подключением их security-инженера на разделы выплат. SLA-период 4 месяца с реакцией P1 < 30 минут (выплаты — критичная операция).

Что получилось. Сдача с задержкой 6 рабочих дней (на 11-й неделе обнаружился пограничный кейс с reconciliation одного из маркетплейсов, требующий двух дополнительных адаптеров). Прохождение 128 из 134 критериев на первой приёмке. Инструкция по эксплуатации на 72 страницы. Передача за 8 недель (длиннее обычного из-за критичности модуля): walkthrough, парное программирование на пяти первых production-инцидентах. За SLA-период — 7 P1-инцидентов (все связаны с изменениями API маркетплейсов и расхождениями данных), средняя реакция 18 минут, фикс — в среднем 3,2 часа.

TCO. Прямо: 6,3 млн + 0,8 млн SLA = 7,1 млн. Альтернатива в найме senior с fintech-опытом: 3 человека × 8 месяцев разработки × 0,4 млн ЗП + поддержка 16 месяцев + налоги + HR (особенно сложный для fintech-опыта) ≈ 28-32 млн рублей. Разница — 4х в пользу под ключ для специализированного вертикального модуля.

Урок. Вертикальная специализация вендора экономит не только время, но и риск. Команда без опыта расчётов в маркетплейсах не учла бы 4-5 ключевых кейсов (rolling-reserve timeline, обработка возвратов после расчётного периода, double-entry для аудита), которые мы заложили в архитектуру с самого начала. Discovery-фаза с участием senior с отраслевым опытом — главный фактор успеха.

Decision matrix: какая вертикаль требует специализации вендора

Не все отрасли одинаково чувствительны к вертикальной экспертизе. Этот чек-лист помогает понять, насколько важна специализация для вашего проекта.

Вертикаль	Требует спец. вендора	Доля compliance в проекте	Доля интеграций	Типовой срок
B2B SaaS общего профиля	Желательно	5-15%	20-30%	8-14 нед
B2B SaaS с мультитенант + SSO	Желательно	10-15%	25-35%	10-16 нед
Marketplace-агрегатор	Обязательно	15-25%	40-60%	12-20 нед
Marketplace продавца	Желательно	10-20%	35-50%	10-16 нед
Fintech (KYC/AML)	Обязательно	30-40%	25-35%	14-22 нед
Fintech (платёжные шлюзы)	Обязательно	25-35%	40-55%	12-20 нед
Healthtech (ЕГИСЗ)	Обязательно	30-50%	25-40%	14-24 нед
Healthtech (приложения для пациентов)	Желательно	20-30%	15-25%	10-16 нед
Retail / E-commerce	Желательно	10-15%	30-45%	10-16 нед
EdTech	Желательно	5-10%	20-30%	8-14 нед
Logistics	Желательно	10-20%	40-55%	10-18 нед

Правило: чем выше доля compliance, тем критичнее опыт вендора в отрасли. Универсальная команда в fintech или healthtech приводит к серьёзным проблемам на финальной приёмке.

Сравнительная таблица: вертикальный вендор vs универсальный для fintech-модуля

Параметры для типового fintech-модуля среднего размера (объём работ 1800-2800 человеко-часов).

Параметр	Вертикальный вендор (fintech-опыт 3+ лет)	Универсальный вендор
Срок проекта	14-18 недель	18-26 недель (+ доп. итерации)
Бюджет	4-7 млн ₽	3-5 млн ₽ (+ доработки +1-2 млн ₽)
Compliance-документация	Параллельно разработке, готова к security audit	Часто оставляется на конец, переделывается
Знание регуляторики (ЦБ, 152-ФЗ)	Из коробки	Обучение по ходу, риск пропустить требование
Готовые шаблоны архитектуры	Reconciliation, double-entry, audit-логи — готовы	С нуля проектируется
Партнёрские отношения с типовыми вендорами (НСПК, СБП)	Есть, ускоряют интеграцию 2-3х	Нет, согласование через тех. поддержку
Готовые наборы edge cases для тестов	Есть, 60-80% покрытие типовых сценариев	С нуля собирается
Security audit перед production	В стандарте проекта	Часто не учитывается изначально
Риск регуляторных проблем после запуска	Низкий	Высокий (типовая причина проблем — пропуск требования)
Итоговая стоимость с учётом доработок и рисков	4-7 млн ₽ (в плане)	5-9 млн ₽ (по факту с доработками)

Дешевле — не значит выгоднее. В fintech и healthtech универсальный вендор обычно оказывается дороже на горизонте проекта из-за compliance-доработок.

Чек-лист валидации вертикального вендора

Перед подписанием контракта 4-8 млн рублей с вендором, заявляющим вертикальную экспертизу.

• Проверьте 3+ реальных проекта в той же отрасли за 2 года. Не «один кейс трёхлетней давности», а несколько проектов в активной фазе.
• Запросите рекомендации от tech lead’ов прошлых клиентов в отрасли. 15-минутный звонок с прошлым CTO даст больше, чем 5 страниц презентаций.
• Проведите технический интервью с senior из их команды. Не «они нам прислали резюме senior», а живой разговор о конкретных вызовах в отрасли.
• Проверьте готовность к compliance-документации. Запросите шаблоны: модель угроз, политика обработки персональных данных, процедура реагирования на инциденты. Если их нет — компания вертикальной экспертизой не обладает.
• Проверьте партнёрские отношения с отраслевыми вендорами. Для fintech — НСПК, СБП, банки. Для healthtech — оператор ЕГИСЗ. Для retail — операторы ОФД. Это конкретные имена контактов, не «у нас есть знакомые в отрасли».
• Уточните роль security в проекте. Должен быть выделенный security-инженер (или внешний консультант) на critical-разделы, не «backend разработчик заодно делает security».
• Согласуйте сразу финальный pen-test перед production. Это включается в стоимость, а не «опция на потом».
• Убедитесь, что юридическое сопровождение клиента подключается с первого дня. Compliance-документация согласуется с юристами клиента параллельно разработке, не в последнюю неделю.