Почему смета на приложение выросла на 40% в середине проекта

Вы согласовали смету, подписали договор и уже видите будущее приложение. А потом — «небольшая правка», «вот ещё одна важная деталь», «давайте добавим эту фичу, она займёт пару дней». Через три месяца подрядчик присылает обновлённый счёт, и цифра на 30–50% больше того, на что вы рассчитывали.

Это классический scope creep — «расползание рамок» проекта. Он не возникает из жадности или недобросовестности. Он вырастает из расплывчатых начальных договорённостей и предсказуемых ловушек, в которые попадают даже опытные заказчики. В этой статье мы разберём механику app development scope creep cost, покажем, как именно бюджеты раздуваются, и дадим три конкретных пункта в договоре, которые это предотвращают.

---

Что такое scope creep и почему он стоит дорого

Scope creep — это постепенное расширение объёма работ без пересмотра сроков и бюджета. Ключевое слово — «постепенное». Ни один заказчик не приходит к подрядчику и не говорит: «Добавьте ещё 40% задач за те же деньги». Это происходит по чуть-чуть.

Типичная цепочка событий:

1. Первоначальное ТЗ содержит фразы вроде «интуитивный интерфейс», «стандартный онбординг» или «профиль пользователя».
2. В процессе разработки выясняется, что у заказчика и команды разные представления об этих словах.
3. Заказчик просит уточнить — добавить шаг, переделать экран, добавить поле.
4. Каждое уточнение кажется мелочью, но вместе они складываются в десятки часов работы.
5. Подрядчик выставляет дополнительный счёт — и конфликт неизбежен, потому что заказчик считал всё это частью исходной задачи.

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

---

Три главных источника расползания рамок

1. Нечёткие пользовательские сценарии

«Пользователь может редактировать профиль» — это одна строка в ТЗ. Но что за ней скрывается? Можно ли менять аватар? Как обрабатывается старый аватар — удаляется или хранится? Нужна ли верификация нового e-mail? Что происходит, если пользователь закрыл приложение во время загрузки?

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

2. Итерации на основе «живых» впечатлений

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

Стандартный договор с фиксированной ценой обычно включает один-два раунда правок на каждый экран. Если этот лимит не прописан явно, команда работает «до вашего одобрения» — и каждое новое пожелание входит в общий счёт.

3. Расширение MVP без пересмотра договора

На старте решили делать MVP — минимально жизнеспособный продукт. Потом добавили уведомления («это же просто push, быстро»), потом аналитику («нам нужно знать, что делают пользователи»), потом интеграцию с CRM («без этого продажи не будут работать»).

Каждое из этих решений может быть обоснованным. Но если они принимаются без пересмотра сроков и бюджета, подрядчик либо откажет, либо сделает быстро и плохо, либо выставит отдельный счёт. Ни один из вариантов вас не порадует.

---

Как расплывчатое ТЗ влияет на стоимость: конкретные цифры

Посмотрите на реальные диапазоны стоимости iOS-разработки в 2026 году:

Тип проекта	Стоимость	Типичный срок
Простой MVP	$5 000–15 000	2–4 месяца
Стандартное приложение	$15 000–45 000	4–7 месяцев
Сложное (AI / реалтайм)	$45 000–120 000+	7–12+ месяцев

Теперь добавьте к этому нефиксированный scope creep. Исследования в индустрии показывают, что проекты без строгого управления рамками в среднем выходят на 30–50% дороже исходной оценки — и это консервативная цифра.

Для проекта за $30 000 это дополнительные $9 000–15 000. Не потому что подрядчик нечестный — просто «стандартное приложение» с нечётким ТЗ превращается в полтора стандартных приложения по ходу работы.

Почасовые ставки у разных типов подрядчиков тоже отличаются: агентства берут $150–250/ч, студии-бутики — $60–120/ч, фрилансеры — $20–60/ч. При 50 незапланированных часах это $3 000–12 500 сверх бюджета — в зависимости от того, с кем вы работаете.

---

Три договорных пункта, которые защищают ваш бюджет

Это не юридические тонкости — это рабочие инструменты, которые мы используем во всех наших проектах. Если в вашем договоре этих пунктов нет, попросите их добавить перед подписанием.

Пункт 1: Definition of Done (Определение готовности)

Каждая задача должна иметь явный критерий завершения. Не «реализовать экран профиля», а «пользователь может изменить имя, аватар (JPG/PNG до 5 МБ) и e-mail с подтверждением через письмо; изменения сохраняются мгновенно; ошибки валидации отображаются под полями».

Когда критерий есть — не бывает споров о том, «включалось ли это в смету».

Пункт 2: Change Request Process (Процедура изменений)

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

Это не бюрократия — это защита для обеих сторон. Заказчик видит цену каждого «небольшого добавления» ещё до того, как оно сделано. Подрядчик не работает бесплатно.

Хороший ориентир: изменения до $500 или 4 часов работы можно включить в еженедельный пул гибкости (если он предусмотрен), всё остальное — только через Change Request.

Пункт 3: Scope Freeze Clause (Заморозка рамок)

Примерно за 3–4 недели до завершения проекта рамки фиксируются: новые функции не добавляются, идут только финальное тестирование и исправление багов. Все новые идеи уходят в backlog следующей версии.

Без этого пункта финальная фаза — самая уязвимая. Продукт почти готов, и именно тогда появляется желание «пока не выпустили, добавим ещё вот это». Каждое такое добавление отодвигает дату релиза и увеличивает стоимость.

---

Что сделать до подписания договора

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

• Убедитесь, что в ТЗ прописаны конкретные экраны, а не только функции
• Попросите команду описать, что не входит в проект — это часто важнее, чем то, что входит
• Зафиксируйте количество раундов правок по дизайну (обычно 2–3 на экран)
• Убедитесь, что Change Request-процедура прописана в договоре явно
• Спросите, что происходит, если вы хотите добавить новую функцию — услышьте ответ до старта
• Попросите план работ с промежуточными вехами: каждые 2–3 недели должен быть осязаемый результат

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

---

Как мы работаем в Fera Tech

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

Если вы хотите посмотреть, как мы строим продукты, — загляните в раздел с нашими работами. Там есть примеры из разных категорий: от MVP за несколько месяцев до сложных AI-продуктов.

По нашим собственным приложениям — Launchcast и Clove AI — мы тоже начинали с чётко зафиксированных рамок и итерировали от версии к версии. Именно это позволяет добавлять функции без хаоса.

---

Частые вопросы

Q: Если я работаю по Time & Materials, scope creep мне не страшен?

Не совсем. T&M-модель делает стоимость каждого изменения прозрачной — вы видите, сколько стоит каждый дополнительный час. Но без управления рамками проект всё равно может уйти далеко от исходного плана по срокам и бюджету. Change Request-процедура нужна при любой модели.

Q: Как понять, что ТЗ достаточно детальное?

Хорошая проверка: попросите двух разных разработчиков прочитать ваше ТЗ и описать, что они будут делать. Если ответы сильно расходятся — ТЗ недостаточно конкретное. Детальное ТЗ не должно оставлять пространства для интерпретаций в ключевых сценариях.

Q: Студия говорит, что Discovery-фаза стоит отдельно. Это нормально?

Да, это нормальная практика. Discovery — это 2–4 недели структурированной работы: интервью, сценарии, прототип, техническая оценка. Её стоимость обычно $2 000–8 000 в зависимости от сложности проекта. Зато после неё вы получаете договор с конкретным scope — и риск неприятных сюрпризов падает кратно.

---

Если вы сейчас выбираете подрядчика или уже получили несколько смет и хотите разобраться, что в них реально входит — напишите нам. Мы разберём вашу ситуацию, посмотрим на ТЗ и честно скажем, что может пойти не так. Никаких обязательств.

Связаться с нами — или сразу посмотрите наши услуги, если хотите понять, как мы выстраиваем процесс с нуля.