Как проверить, реалистичны ли сроки разработки SaaS-сервиса перед оплатой аванса

Какие документы запросить у подрядчика до подписания договора

Перед подписанием договора на разработку 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-разработки

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

Как пользоваться таблицей: пройдитесь по каждому критерию и сопоставьте ответ подрядчика с нормой. Если хотя бы три критерия попали в колонку «Красный флаг» — сроки, скорее всего, нереалистичны.

5 красных флагов, которые указывают на нереалистичные дедлайны

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

1. «Укладываемся за месяц» без детализации. Если подрядчик называет срок «до месяца» для полноценного SaaS-продукта с авторизацией, платёжной системой и админкой — это нереалистичная оценка. Только MVP с базовым функционалом занимает 4–6 недель при команде из 3–4 разработчиков.

2. Отсутствие спринтов в плане. Agile-подход предполагает итеративную разработку. Если подрядчик предлагает «водопадную» модель без промежуточных демо — он либо не планирует показывать промежуточные результаты, либо не умеет работать по спринтам.

3. Заниженная оценка интеграций. Подключение платёжной системы (ЮKassa, Stripe), CRM, сервиса рассылок и аналитики — это минимум 2–4 недели на каждую интеграцию. Если подрядчик оценивает все интеграции в одну строку «включено» — он не учитывает реальную сложность.

4. Нет отдельного бюджета на QA. Тестирование — это 20–30 % от общего объёма работ в SaaS-проекте. Если подрядчик не выделяет QA отдельной строкой в смете, значит он планирует тестировать «по ходу» или передаст продукт без полноценного тестирования.

5. Договор без штрафов за срыв сроков. Если подрядчик отказывается фиксировать штрафы за просрочку — он сам не верит в свои сроки. Мы рекомендуем также сравнить условия договоров SaaS-сервисов: сроки, штрафы и тарифы, чтобы понять рыночные нормы.

Чек-лист: что проверить за 24 часа до перевода аванса

За сутки до перевода предоплаты пройдитесь по этому чек-листу. Каждый пункт — конкретное действие, которое занимает от 15 минут до часа.

1. Сверьте смету с ТЗ. Откройте техническое задание и смету рядом. Убедитесь, что каждая функциональная единица из ТЗ учтена в смете. Если в ТЗ описаны 15 экранов, а в смете — 8 задач, значит подрядчик что-то пропустил или намеренно занизил объём.

2. Проверьте квалификацию команды. Запросите профили ключевых специалистов: тимлида, бэкенд- и фронтенд-разработчиков, дизайнера. Проверьте их портфолио на GitHub или в профессиональных соцсетях. Убедитесь, что команда уже работала с вашим стеком технологий.

3. Оцените реалистичность сроков самостоятельно. Возьмите рыночную ориентировку: разработка MVP SaaS-платформы с базовым функционалом (авторизация, личный кабинет, оплата, админка) занимает 8–12 недель при команде из 4–5 человек. Если подрядчик обещает 3–4 недели — это нереалистично.

4. Зафиксируйте вехи в договоре. Убедитесь, что в договоре прописаны конкретные даты: завершение MVP (неделя 6–8), передача на бета-тестирование (неделя 10–12), финальный релиз (неделя 12–14). Каждая веха должна сопровождаться актом приёмки.

5. Проверьте наличие резерва. В реальных проектах всегда есть непредвиденные расходы. Хорошая смета содержит резерв в 15–20 % от общей суммы. Если подрядчик не заложил резерв — при первых же изменениях в требованиях сроки поедут.

6. Уточните процедуру изменения требований. В процессе разработки неизбежно появятся новые задачи. Убедитесь, что в договоре прописан порядок изменения требований: как оформляется заявка, как пересчитываются сроки и стоимость.

7. Подтвердите права на код. По умолчанию права на исходный код переходят к заказчику только при наличии соответствующего пункта в договоре. Убедитесь, что это зафиксировано. В противном случае вы рискуете остаться без кодовой базы при разрыве отношений.

Когда сроки разработки 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 человек.