Какие документы запросить у подрядчика до подписания договора
Перед подписанием договора на разработку SaaS-платформы запросите у подрядчика пакет документов. Это не формальность — каждый из них помогает оценить, насколько реалистичны обещанные сроки.
1. Детальная смета с разбивкой по спринтам. Попросите подрядчика предоставить смету, разделённую на спринты по 1–2 недели. Каждый спринт должен содержать перечень задач, оценку трудозатрат в часах или story points и ответственного исполнителя. Если подрядчик называет только общую сумму и общий срок без детализации — это первый тревожный сигнал.
2. Портфолио аналогичных проектов. Запросите 2–3 кейса схожих SaaS-продуктов: сколько времени заняла разработка, какой был стек технологий, были ли срывы сроков. Реальные кейсы подтверждают компетентность команды и позволяют сопоставить обещания с фактами.
3. Техническое задание (ТЗ). ТЗ — это основа договора. В нём должны быть описаны функциональные и нефункциональные требования, архитектура системы, интеграции с внешними API и требования к производительности. Чем детальнее ТЗ, тем точнее оценка сроков. Мы рекомендуем также сравнить методы приемки мобильного приложения по ТЗ и сценариям, чтобы понять, как подрядчик планирует тестирование.
4. План управления рисками. Хороший подрядчик заранее обозначает риски: зависимость от сторонних API, возможные изменения в требованиях, кадровые ротации. Если подрядчик не может назвать ни одного риска — он либо неопытен, либо скрывает реальную картину.
5. Соглашение об уровне обслуживания (SLA). SLA-документ фиксирует обязательства подрядчика по срокам реагирования, доступности сервиса и штрафам за срывы. Запросите проект SLA до подписания основного договора.
6. Подтверждение соответствия 152-ФЗ. Если ваш SaaS-сервис будет обрабатывать персональные данные, подрядчик обязан подтвердить, что архитектура системы соответствует требованиям Федерального закона № 152-ФЗ «О персональных данных». Подробнее о том, как это проверить, мы рассказывали в статье о проверке соответствия SaaS-сервиса требованиям 152-ФЗ.
7. Договор с фиксированными вехами. В договоре должны быть прописаны конкретные даты: завершение MVP, передача на тестирование, финальный релиз. Без фиксированных вех любой срок превращается в абстракцию.
---
Таблица проверки: 8 критериев реалистичности сроков SaaS-разработки
Мы собрали восемь критериев, по которым можно оценить, соответствуют ли обещанные сроки реальности. Используйте эту таблицу как инструмент верификации — сверяйте ответы подрядчика с каждым пунктом.
| Критерий | Норма | Красный флаг |
|---|---|---|
| Разбивка по спринтам | Смета детализирована по 1–2 неделям | Только общий срок без спринтов |
| Оценка трудозатрат | Каждая задача оценена в часах или story points | Оценка дана «на глаз» без единиц |
| Портфолио | 2+ аналогичных кейса с реальными сроками | Нет завершённых SaaS-проектов |
| Команда | Названы роли и количество специалистов | «Наша команда справится» без деталей |
| Риски | Есть раздел «Риски» в ТЗ или договоре | Риски не упоминаются вовсе |
| Тестирование | Выделен отдельный спринт на QA | Тестирование «включено в разработку» |
| Интеграции | Каждая внешняя интеграция оценена отдельно | Интеграции учтены общей строкой |
| Деплой и поддержка | Есть план деплоя и post-launch поддержки | Релиз = финал, без поддержки |
Как пользоваться таблицей: пройдитесь по каждому критерию и сопоставьте ответ подрядчика с нормой. Если хотя бы три критерия попали в колонку «Красный флаг» — сроки, скорее всего, нереалистичны.
---
5 красных флагов, которые указывают на нереалистичные дедлайны
По результатам нашего тестирования десятков коммерческих предложений мы выделили пять признаков, которые почти гарантированно указывают на завышение сроков.
1. «Укладываемся за месяц» без детализации. Если подрядчик называет срок «до месяца» для полноценного SaaS-продукта с авторизацией, платёжной системой и админкой — это нереалистичная оценка. Только MVP с базовым функционалом занимает 4–6 недель при команде из 3–4 разработчиков.
2. Отсутствие спринтов в плане. Agile-подход предполагает итеративную разработку. Если подрядчик предлагает «водопадную» модель без промежуточных демо — он либо не планирует показывать промежуточные результаты, либо не умеет работать по спринтам.
3. Заниженная оценка интеграций. Подключение платёжной системы (ЮKassa, Stripe), CRM, сервиса рассылок и аналитики — это минимум 2–4 недели на каждую интеграцию. Если подрядчик оценивает все интеграции в одну строку «включено» — он не учитывает реальную сложность.
4. Нет отдельного бюджета на QA. Тестирование — это 20–30 % от общего объёма работ в SaaS-проекте. Если подрядчик не выделяет QA отдельной строкой в смете, значит он планирует тестировать «по ходу» или передаст продукт без полноценного тестирования.
5. Договор без штрафов за срыв сроков. Если подрядчик отказывается фиксировать штрафы за просрочку — он сам не верит в свои сроки. Мы рекомендуем также сравнить условия договоров SaaS-сервисов: сроки, штрафы и тарифы, чтобы понять рыночные нормы.
---
Когда сроки разработки SaaS-сервиса точно не соответствуют реальности
Существуют ситуации, в которых обещанные сроки заведомо нереалистичны. Редакция miniwebsansar.com выделила шесть таких случаев на основе анализа коммерческих предложений.
1. Полноценный SaaS за 4 недели. Если подрядчик обещает готовый продукт с авторизацией, биллингом, аналитикой и админкой за месяц — это невозможно. Только настройка платёжной интеграции с ЮKassa или Stripe занимает 1–2 недели с учётом тестирования.
2. Команда из 1–2 человек на крупный проект. SaaS-платформа с несколькими модулями требует минимум 4–5 специалистов: тимлид, 2 разработчика, дизайнер, QA-инженер. Два разработчика не справятся с проектом за обещанные сроки.
3. Нет отдельного этапа на тестирование. Если в смете не выделен спринт на QA — подрядчик планирует тестировать «по ходу». Это приведёт к накоплению багов и переносу релиза на 2–4 недели.
4. Подрядчик не может показать готовые проекты. Если портфолио пустое или состоит из учебных проектов — нет оснований доверять оценке сроков. Опытный подрядчик всегда имеет 2–3 кейса с реальными сроками и результатами.
5. Стоимость ниже рыночной на 40 % и более. Средняя стоимость разработки SaaS-платформы в 2026 году — от 2 до 8 млн рублей в зависимости от сложности. Если подрядчик предлагает 500 тыс. за аналогичный объём — он либо занизил объём работ, либо привлечёт джуниоров.
6. Договор не содержит пункта о штрафах. Если подрядчик отказывается от штрафных санкций за срыв сроков — он не уверен в своих оценках. Рыночная норма для IT-подрядов — штраф 0,1–0,5 % от суммы договора за каждый день просрочки.
> По данным аналитиков CNews, средний срок разработки SaaS-платформы средней сложности в России в 2025 году составил 14–18 недель при команде из 5–6 человек.
---
Какой минимальный срок разработки SaaS-сервиса?
Минимальный срок для MVP базового SaaS-продукта (авторизация, личный кабинет, базовая оплата) — 6–8 недель при команде из 3–4 человек. Сроки менее 4 недель для продукта с аналогичным функционалом нереалистичны.
Что делать, если подрядчик срывает сроки?
Зафиксируйте факт просрочки письменно, потребуйте обновлённый план с новыми датами и примените штрафные санкции, предусмотренные договором. Если просрочка превышает 30 дней, имеет смысл провести независимый аудит кодовой базы.
Как проверить качество кода до финального релиза?
Проведите code-ревью на промежуточном этапе — после завершения MVP, проверьте покрытие тестами (минимум 70 % для критичных модулей), убедитесь в наличии документации по API. Подробнее о методах проверки мы рассказывали в статье о сравнении методов приемки мобильного приложения по ТЗ и сценариям.