Вопросы и ответы

Как понять, реальны ли сроки разработки цифрового сервиса до подписания договора?

Автор и проверка: Алексей Воронов, редакционный координатор miniwebsansar.com · Факты, документы, риски и применимость · Обновлено: 29 сентября 2025 г.

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

Критерии выбора

Что считать реалистичным сроком разработки

Реалистичный срок — это не просто дата запуска. Это срок, в котором уже учтены:

• сбор требований;

• проектирование пользовательских сценариев;

• дизайн интерфейсов;

• разработка backend и frontend;

• мобильная разработка, если нужен iOS/Android;

• интеграции с платежами, CRM, ERP, картами, доставкой, аналитикой;

• тестирование;

• исправление ошибок;

• публикация, настройка серверов и передача доступов;

• гарантийная поддержка после запуска.

Например, простой личный кабинет или MVP веб-сервиса может занимать 6–10 недель. Мобильное приложение с авторизацией, каталогом, оплатой и push-уведомлениями — 3–5 месяцев. Сервис с несколькими ролями пользователей, интеграциями, админ-панелью и аналитикой — 4–8 месяцев и дольше.

В 2026 году часть работ действительно ускоряется за счет готовых компонентов, low-code-инструментов и AI-помощников. Но это не отменяет время на согласования, безопасность, тестирование, интеграции, публикацию в сторах и исправление ошибок. Быстрее можно собрать прототип, но не всегда можно быстрее выпустить надежный продукт.

Какие документы нужно проверить до договора

До подписания договора попросите у подрядчика не общую презентацию, а рабочий комплект документов:

1. Техническое задание или product brief

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

2. Коммерческое предложение

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

3. Календарный план

Проверьте, разбит ли срок на этапы: 3–7 дней на уточнение требований, 1–2 недели на прототип, 2–6 недель на разработку модуля, 1–3 недели на тестирование.

4. Смета по блокам

Хорошая смета показывает, сколько стоят аналитика, дизайн, backend, frontend, мобильная часть, интеграции, тестирование, DevOps и поддержка.

5. Порядок правок

Должно быть ясно, сколько раундов правок входит в цену, как фиксируются изменения и сколько стоит дополнительная переделка.

6. Гарантия и поддержка

Уточните срок гарантии: например, 14, 30, 60 или 90 дней после релиза. Отдельно проверьте, что считается гарантийной ошибкой, а что новой доработкой.

7. Документы на материалы или услугу

Если используются платные шаблоны, библиотеки, шрифты, изображения, SDK, API или сторонние сервисы, нужно понимать, на кого оформлены лицензии и кто оплачивает подписки.

Таблица проверки сроков до подписания договора

| Что проверить | Хороший признак | Тревожный признак |

|---|---|---|

| ТЗ | Есть функции, роли, сценарии, ограничения, критерии приемки | «Все обсудим по ходу» |

| Смета | Разбита по этапам и типам работ | Одна строка: «разработка сервиса» |

| Сроки | Есть календарный план с буферами | Обещают точную дату без уточнений |

| Команда | Указаны роли: аналитик, дизайнер, разработчики, QA, менеджер | «Один специалист все сделает» для сложного продукта |

| Интеграции | Перечислены API, платежи, CRM, уведомления, аналитика | Интеграции названы «простыми» без проверки документации |

| Правки | Есть лимит раундов и цена дополнительных изменений | Все правки обещают бесплатно устно |

| Гарантия | Прописан срок и объем гарантийных исправлений | Гарантия не упоминается |

| Поддержка | Есть условия после запуска | После релиза подрядчик «передаст архив» |

| Файлы и доступы | Описан формат макетов, исходников, репозитория, серверов | Непонятно, кто владеет кодом и аккаунтами |

| Риски | Есть список зависимостей и допущений | Все выглядит слишком гладко |

Сравнение вариантов

Вариант 1: фиксированный срок и фиксированная цена

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

Когда подходит:

• есть подробное ТЗ;

• функции заранее согласованы;

• интеграции понятны;

• не ожидается частая смена требований;

• важен контроль бюджета.

Что проверить:

• что считается изменением объема работ;

• сколько правок входит в цену;

• есть ли штрафы или компенсации за просрочку;

• кто отвечает за задержки со стороны клиента;

• как принимаются этапы.

Риск: если ТЗ неполное, подрядчик может либо заложить большой запас в цену, либо выставлять дополнительные счета за каждое уточнение.

Вариант 2: поэтапная разработка

При поэтапном подходе сервис делят на блоки: аналитика, прототип, дизайн, MVP, интеграции, тестирование, релиз, поддержка. Это часто самый безопасный вариант до старта сложного продукта.

Пример этапов:

| Этап | Ориентир по сроку | Что должно быть на выходе |

|---|---:|---|

| Уточнение требований | 3–7 дней | список функций, рисков, ограничений |

| Прототип | 1–2 недели | кликабельные экраны без финального дизайна |

| Дизайн | 2–4 недели | макеты ключевых экранов |

| Разработка MVP | 6–12 недель | рабочая первая версия |

| Тестирование | 1–3 недели | список исправленных ошибок |

| Запуск | 2–7 дней | публикация, доступы, инструкции |

| Поддержка | 14–90 дней | исправление гарантийных ошибок |

Когда подходит:

• продукт еще уточняется;

• есть несколько пользовательских ролей;

• нужны интеграции;

• важно запускать MVP, а не ждать идеальную версию.

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

Вариант 3: срочная разработка

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

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

• что реально сделать за 3–7 дней;

• какие функции уйдут во вторую очередь;

• сколько будет стоить ускорение;

• сколько специалистов подключат;

• что будет с тестированием;

• какая гарантия сохранится;

• сколько стоит переделка после срочного запуска.

Пример: если стандартный MVP оценивают в 10 недель, срочная версия за 4 недели может включать только авторизацию, основной сценарий, простую админ-панель и ручную обработку части операций. Полная автоматизация, аналитика, сложные роли и интеграции могут перейти во второй этап.

Риск: срочная разработка часто увеличивает стоимость на 20–50% и повышает вероятность технического долга. Если подрядчик обещает срочный запуск без сокращения объема, это повод проверить расчет повторно.

Вариант 4: Time & Materials

Модель Time & Materials означает оплату фактического времени команды. Она подходит, когда продукт развивается итерационно и невозможно заранее зафиксировать весь объем.

Когда подходит:

• вы строите SaaS, маркетплейс, мобильный продукт или внутреннюю платформу;

• требования будут меняться после тестирования гипотез;

• нужны регулярные релизы;

• важна гибкость.

Что запросить до старта:

• ставки специалистов;

• недельную загрузку команды;

• формат отчетов;

• лимит бюджета на спринт;

• план ближайших 2–4 недель;

• демо результата в конце каждого спринта.

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

Когда заявленные сроки не подходят

Заявленный срок стоит считать сомнительным, если подрядчик:

• не просит ТЗ, но сразу называет точную дату;

• не задает вопросов о пользователях, ролях, интеграциях и нагрузке;

• не показывает этапы;

• не закладывает время на тестирование;

• обещает «любые правки бесплатно»;

• не обсуждает поддержку после запуска;

• не уточняет формат файлов, исходников и доступов;

• не говорит, кто оплачивает сторонние сервисы;

• не фиксирует ответственность сторон.

Типовые риски в цифровых сервисах: нет ТЗ, размытые сроки, устные правки, скрытая стоимость материалов, неподходящий формат файлов или отсутствие поддержки. Например, после запуска может выясниться, что макеты переданы в неудобном формате, исходники не принадлежат заказчику, платежный модуль требует отдельной лицензии, а исправления после релиза считаются платными доработками.

Что может пойти не так

1. Срок сорвется из-за неполного ТЗ

Если не описаны роли пользователей и сценарии, разработчики будут уточнять их уже в процессе.

2. Интеграция окажется сложнее

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

3. Правки станут отдельным бюджетом

Устные договоренности о правках часто превращаются в споры: заказчик считает это исправлением, подрядчик — новой задачей.

4. Запуск задержится из-за тестирования

Если QA не заложен в план, ошибки найдут уже пользователи.

5. Не будет поддержки после релиза

Сервис запустили, но некому обновлять, исправлять и сопровождать его.

6. Файлы или код передадут не полностью

В договоре нужно заранее указать передачу исходников, доступов, репозитория, документации и прав на результат.

1. Проверьте портфолио

Попросите 2–3 примера похожих цифровых сервисов: мобильные приложения, личные кабинеты, SaaS-продукты, внутренние панели, маркетплейсы или интеграционные решения. Важно не просто увидеть красивые экраны, а понять:

• какую задачу решал продукт;

• сколько длилась разработка;

• какие были роли пользователей;

• были ли интеграции;

• кто поддерживает продукт сейчас.

2. Сравните 3 сметы

Запросите у подрядчика:

• базовую смету — минимальный рабочий объем;

• оптимальную смету — сбалансированный вариант;

• срочную смету — что можно ускорить и за какую доплату.

В каждой смете должны быть сроки, состав работ, гарантия и стоимость переделки.

3. Проверьте техническое задание

В ТЗ должны быть:

• цели сервиса;

• список функций;

• пользовательские роли;

• основные сценарии;

• платформы: web, iOS, Android;

• интеграции;

• требования к безопасности;

• требования к нагрузке;

• языки интерфейса;

• критерии приемки.

Если ТЗ занимает одну страницу для сложного продукта, срок почти невозможно оценить точно.

4. Разберите календарный план

Попросите показать, что будет готово через:

• 3–7 дней;

• 2 недели;

• 1 месяц;

• половину проекта;

• к дате релиза.

У каждого этапа должен быть результат: прототип, макеты, модуль, тестовая сборка, акт приемки, инструкция, доступы.

5. Уточните порядок правок

Зафиксируйте:

• сколько раундов правок входит в цену;

• в какие сроки вы должны давать обратную связь;

• что считается ошибкой;

• что считается новой функцией;

• какая ставка или фиксированная цена у дополнительных работ.

6. Проверьте гарантию и поддержку

До договора уточните:

• срок гарантии;

• время реакции на критические ошибки;

• входит ли исправление багов;

• сколько стоит поддержка после гарантии;

• кто обновляет серверы, библиотеки, сертификаты и интеграции.

7. Проверьте права и доступы

В договоре должны быть указаны:

• передача прав на код и дизайн;

• доступ к репозиторию;

• доступ к серверу или облаку;

• доступ к аналитике;

• доступ к аккаунтам публикации приложений;

• список используемых сторонних материалов и сервисов.

8. Задайте подрядчику контрольные вопросы

Полезные вопросы до договора:

• Что именно будет готово через первую неделю?

• Какие 3 риска вы видите в проекте?

• Какие функции могут увеличить срок?

• Что не входит в эту смету?

• Сколько стоит дополнительный экран, интеграция или сценарий?

• Кто будет тестировать продукт?

• Что произойдет, если мы изменим требования?

• Какой минимальный объем можно запустить как MVP?

• Кто отвечает за публикацию и поддержку?

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

Можно ли верить сроку, если подрядчик обещает разработку за 2 недели?

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

Что важнее проверить: цену или срок?

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

Как понять, что подрядчик заложил тестирование?

В календарном плане должен быть отдельный этап QA или тестирования. В смете должны быть часы или стоимость тестировщика. Также попросите указать, какие виды проверки будут выполнены: функциональное тестирование, проверка форм, платежей, ролей, адаптивности, уведомлений и критических сценариев.

Нужно ли подписывать договор до финального ТЗ?

Можно подписать короткий договор на предпроектную аналитику: 3–7 дней или 1–2 недели, чтобы получить ТЗ, прототип, оценку сроков и смету. Но подписывать большой договор на разработку без понятного ТЗ рискованно.

Что делать, если разные подрядчики дают сроки с разбросом в 2–3 раза?

Сравните не только сроки, но и состав работ. Один подрядчик может считать только разработку, другой — аналитику, дизайн, тестирование, DevOps, поддержку и документацию. Попросите всех пересчитать по одной структуре: базовый, оптимальный и срочный вариант.

Какой срок гарантии считается нормальным?

Для небольших сервисов часто встречается гарантийный период 14–30 дней, для более сложных продуктов — 30–90 дней. Важно не только количество дней, но и то, что именно входит в гарантию: исправление ошибок, найденных в согласованном функционале, или полноценная поддержка с новыми доработками.

Как зафиксировать реальность сроков в договоре?

В договоре и приложениях должны быть календарный план, ТЗ, смета, критерии приемки, порядок правок, условия изменения сроков, гарантия, поддержка, передача прав и доступов. Чем меньше устных обещаний, тем выше шанс, что срок будет управляемым.